Bootloader Build_Clover.command, another Script to build standard Clover (or customized)

[KGP-iMacPro]

55 minutes ago, Philip Petev said:

 

Both MacPorts and Brew don't support Mojave yet, so I think the problem is with some or both of them. The only functional difference between his script and mine is the following line:

export PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin"

at the beginning of the script and I think that's not the reason for the script to work on your machine. I also have MacPorts installed on mine, so /opt/local/bin has higher priority than the one above and yet:

philip@HackMini:~$ which ar
/usr/bin/ar
philip@HackMini:~$

That means MacPorts has no such binary and that binary (or more likely the configure script locates a wrong one) is the cause on your machine according to the mtoc build log.

 

o.k. successful build now again (no KP during make gettext) with Build_Clover_mojave_Xcode10.command after some apparent Xcode 10 command line tool update. See log below:

 

 Build_Clover_mojave_Xcode10.command-LOG.rtf

 

As you see, Build_Clover_mojave_Xcode10.command also uses the Xcode 8 toolchain. 

 

I agree that the get text issue is related with brew and MacPorts and only can be removed in my case by the additional export PATH implementation...

 

But still...

 

Why Build_Clover.command v.4.8.7 uses Xcode 5 toolchain and crashes at the mtoc creation? This is I guess not export PATH related and has been fixed in my understanding already yesterday by @vector sigma.. 

 

Well.. could be that I aim totally wrong.

 

You certainly know better what you did and implemented and what might cause the actual problems.

 

Sorry for all troubles, questions an doubts... 

 

 

 

Edited June 16, 2018 by KGP-iMacPro

[FredWst]

15 minutes ago, Philip Petev said:

Something like a log maybe? No one here is a diviner.

 

Hum no issue with build. maybe some compiler option ?

Archive.zip with working and not working one, size is not the same.

It's just what I can say.

Edited June 16, 2018 by FredWst

[vector sigma]

1 hour ago, Philip Petev said:

Both MacPorts and Brew don't support Mojave yet, so I think the problem is with some or both of them. The only functional difference between his script and mine is the following line:

Hi, also the checkXcode() is not working because is still return XCODE5, can you test by your self:

#!/bin/bash

xcversion="$(echo 'Xcode 10.0' | grep 'Xcode' | awk '{print $NF}')"
	case "$xcversion" in
		[1-6]* | 7 | 7.[0-2]*) XCODE="XCODE5"; LTO_FLAG="--no-lto";;
		7.[34]*) XCODE="XCODE5";;
		[89]* | 10*) XCODE="XCODE8";;
		*) echo "Unknown Xcode version format, exiting!\n"; exit 1;;
	esac
echo $XCODE

 You should at least IMO do that (and anyway next Xcode 11 will not work):

[4-6]* | 7 | 7.[0-2]*) XCODE="XCODE5"; LTO_FLAG="--no-lto";;

since I have my doubts that anyone can build Clover with Xcode prior to 4.

Also you forgot to export EDK_TOOLS_PATH before sourcing edksetup.sh. That is not working in mojave at first run. It works at the second just because ebuild.sh do that for you. At the first run AptioFix and the new ApfsDriverLoader will not be generated since is your script that build those drivers and not ebuild.sh.

44 minutes ago, KGP-iMacPro said:

Why Build_Clover.command v.4.8.7 uses Xcode 5 toolchain and crashes at the mtoc creation? This is I guess not export PATH related and has been fixed in my understanding already yesterday by @vector sigma.. 

 

You can use this

export PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin" && buildclover

..assuming you previously added the symlink. This is not a bug with this script, but atm is yours, was just a way to force using the right libtool. Anyway a variable for that in the configuration file should be cool..

Edited June 16, 2018 by vector sigma

[KGP-iMacPro]

39 minutes ago, vector sigma said:

Hi, also the checkXcode() is not working because is still return XCODE5, can you test by your self:

#!/bin/bash

xcversion="$(echo 'Xcode 10.0' | grep 'Xcode' | awk '{print $NF}')"
	case "$xcversion" in
		[1-6]* | 7 | 7.[0-2]*) XCODE="XCODE5"; LTO_FLAG="--no-lto";;
		7.[34]*) XCODE="XCODE5";;
		[89]* | 10*) XCODE="XCODE8";;
		*) echo "Unknown Xcode version format, exiting!\n"; exit 1;;
	esac
echo $XCODE

 You should at least IMO do that:

[4-6]* | 7 | 7.[0-2]*) XCODE="XCODE5"; LTO_FLAG="--no-lto";;

since I have my doubts that anyone can build Clover with Xcode prior to 4.

Also you forgot to export EDK_TOOLS_PATH before sourcing edksetup.sh. That is not working in mojave at first run. It works at the second just because ebuild.sh do that for you. At the first run AptioFix and the new ApfsDriverLoader will not be generated since is your script that build those drivers and not ebuild.sh.

You can use this

export PATH="/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin" && buildclover

..assuming you previously added the symlink. This is not a bug with this script, but atm is yours, was just a way to force using the right libtool. Anyway a variable for that in the configuration file should be cool..

 

I totally agree and to add a variable in the configuration file for exporting the path would be just gorgeous! 

[vector sigma]

@Philip Petev, should also be nice to checkout the source from the "development" brach on CupertinoModulePKG (and other dipendencies) since they appear newer.. and is the default branch

Edited June 16, 2018 by vector sigma

[Philip Petev]

1 hour ago, vector sigma said:

Hi, also the checkXcode() is not working because is still return XCODE5, can you test by your self:

#!/bin/bash

xcversion="$(echo 'Xcode 10.0' | grep 'Xcode' | awk '{print $NF}')"
	case "$xcversion" in
		[1-6]* | 7 | 7.[0-2]*) XCODE="XCODE5"; LTO_FLAG="--no-lto";;
		7.[34]*) XCODE="XCODE5";;
		[89]* | 10*) XCODE="XCODE8";;
		*) echo "Unknown Xcode version format, exiting!\n"; exit 1;;
	esac
echo $XCODE

 You should at least IMO do that (and anyway next Xcode 11 will not work):

[4-6]* | 7 | 7.[0-2]*) XCODE="XCODE5"; LTO_FLAG="--no-lto";;

since I have my doubts that anyone can build Clover with Xcode prior to 4.

 

You're right about this one. "10" goes to both "1*" and "10*" case filters and the case operator addresses it to the first one. Just fixed it in 4.8.8 in the work branch, please, test and report.

 

1 hour ago, vector sigma said:

Also you forgot to export EDK_TOOLS_PATH before sourcing edksetup.sh. That is not working in mojave at first run. It works at the second just because ebuild.sh do that for you. At the first run AptioFix and the new ApfsDriverLoader will not be generated since is your script that build those drivers and not ebuild.sh.

 

That's what is line 878 for.

 

35 minutes ago, vector sigma said:

@Philip Petev, should also be nice to checkout the source from the "development" brach on CupertinoModulePKG (and other dipendencies) since they appear newer..

 

The script downloads exactly this branch.

Edited June 16, 2018 by Philip Petev

[vector sigma]

15 minutes ago, Philip Petev said:

That's what is line 878 for.

Just saw, but it is as:

cd "${DIR_MAIN}"/edk2
source edksetup.sh BaseTools

I think it should be: 

cd "${DIR_MAIN}"/edk2
export EDK_TOOLS_PATH="${DIR_MAIN}"/edk2/BaseTools
source edksetup.sh BaseTools

 

Edited June 16, 2018 by vector sigma
typo

[vector sigma]

17 minutes ago, Philip Petev said:

The script downloads exactly this branch.

it downloads the trunk?

svnWithErrorCheck "co --non-interactive --trust-server-cert ${link}/trunk ."

or.. I'm really watching the wrong branch

 

for only these:

https://github.com/CupertinoNet/CupertinoModulePkg
	https://github.com/CupertinoNet/EfiMiscPkg
	https://github.com/CupertinoNet/EfiPkg

should be 

svnWithErrorCheck "co --non-interactive --trust-server-cert ${link}/development ."

?

Edited June 16, 2018 by vector sigma

[Philip Petev]

17 minutes ago, vector sigma said:

Just saw, but it is as:

cd "${DIR_MAIN}"/edk2
source edksetup.sh BaseTools

I think it should be: 

cd "${DIR_MAIN}"/edk2
export EDK_TOOLS_PATH="${DIR_MAIN}"/edk2/BaseTools
source edksetup.sh BaseTools

 

 

Since sourcing the edksetup.sh already exports this variable, that would be the same operation, executed twice. You can see for yourself, just add after line 891 the following:

echo "EDK_TOOLS_PATH=${EDK_TOOLS_PATH}"

and see the result in Terminal.

 

9 minutes ago, vector sigma said:

it dowwnloads the trunk?

svnWithErrorCheck "co --non-interactive --trust-server-cert ${link}/trunk ."

or.. I'm really watching the wrong branch

 

In GitHub, according to this article, trunk points to HEAD and HEAD usually points to the latest commit.

Edited June 16, 2018 by Philip Petev

[vector sigma]

6 minutes ago, Philip Petev said:

Since sourcing the edksetup.sh already exports this variable, that would be the same operation, executed twice.

doesn't work, why ebuild.sh does that.

EDIT

needed in mojave. I agree if that worked until now, but is needed in mojave. May be that will continue working for next betas but now can't.

6 minutes ago, Philip Petev said:

In GitHub, according to this article, trunk points to HEAD and HEAD usually points to the latest commit.

of course, but you have to switch branch otherwise is just the trunk/master

Edited June 16, 2018 by vector sigma

[Philip Petev]

4 minutes ago, vector sigma said:

doesn't work, why ebuild.sh does that

Works perfectly here. If it wasn't working, building the AptioFixPkg and ApfsSupportPkg packages would have failed and it doesn't.

Edited June 16, 2018 by Philip Petev

[vector sigma]

1 minute ago, Philip Petev said:

Works perfectly here. If it wasn't working, building the AptioFixPkg and ApfsSupportPkg packages would have failed and it doesn't.

see my edit at previous post

and this doesn't mean to expect a failure, but just different code.

[Philip Petev]

2 minutes ago, vector sigma said:

see my edit at previous post

May I see it? Try this one and post the result:

 

Quote

Since sourcing the edksetup.sh already exports this variable, that would be the same operation, executed twice. You can see for yourself, just add after line 891 the following:

echo "EDK_TOOLS_PATH=${EDK_TOOLS_PATH}"

and see the result in Terminal.

 

[KGP-iMacPro]

1 minute ago, Philip Petev said:

Works perfectly here. If it wasn't working, building the AptioFixPkg and ApfsSupportPkg packages would have failed and it doesn't.

 

But you are not executing the script under 10.14 and Xcode 10, right? Let me know as soon I should try to run 4.8.8 with Xcode 10 under 10.14. 

[vector sigma]

Just now, Philip Petev said:

May I see it? Try this one and post the result:

 

 

there is this condition:

if [ -f "$DIR/BaseTools/BuildEnv" ]
      then
        export EDK_TOOLS_PATH=$DIR/BaseTools
        . $DIR/BaseTools/BuildEnv
        break
      fi

otherwise..

[Badruzeus]

Hi @Philip Petev why not using "https://" as @apianti suggestion? So far, I also get no issue accessing SF with it. Thanks.

Spoiler

...
"CLOVER_REP",,,"svn://svn.code.sf.net/p/cloverefiboot/code"
"EDK2_REP",,,"svn://svn.code.sf.net/p/edk2/code/trunk/edk2"
...

 

 

Edited June 16, 2018 by Badruzeus

[Philip Petev]

6 minutes ago, Badruzeus said:

Hi @Philip Petev why not using "https://" as @apianti suggestion? So far, I also get no issue accessing SF with it. Thanks.

  Reveal hidden contents

...
"CLOVER_REP",,,"svn://svn.code.sf.net/p/cloverefiboot/code"
"EDK2_REP",,,"svn://svn.code.sf.net/p/edk2/code/trunk/edk2"
...

 

 

Those addresses are adjustable via the config file, but what the heck... Ok, next version will have it by default.

[vector sigma]

9 minutes ago, Philip Petev said:

May I see it? Try this one and post the result:

no need for echoing:

build: command not found

 

[Philip Petev]

3 minutes ago, vector sigma said:

no need for echoing:

build: command not found

 

That doesn't make any sense. Sourcing the edksetup.sh fails for some reason and that's something that has nothing to do with the macOS/Xcode version, but only with the shell.

Alright, start the script like this:

Quote

bash -x Build_Clover.command

then post the results.

Edited June 16, 2018 by Philip Petev

[vector sigma]

6 minutes ago, Philip Petev said:

That doesn't make any sense. Sourcing the edksetup.sh fails for some reason and that's something that has nothing to do with the macOS/Xcode version, but only with the shell.

Sorry Philip but you are wrong. Thake a look at ebuild.sh:

cd "$EDK2DIR"
        export EDK_TOOLS_PATH="${PWD}"/BaseTools
        source ./edksetup.sh BaseTools
        cd "$CLOVERROOT"

they are not crazy. they do that for the same reason. 

Edited June 16, 2018 by vector sigma

[Philip Petev]

No, they're doing it to override the EDK_TOOLS_PATH auto-detection, made by edksetup.sh and later by BaseTools/BuildEnv. There are several checks in both scripts that use the variable if it's already set or define it, if it's not.

 

Sorry Philip but you are wrong. Thake a look at ebuild.sh:

cd "$EDK2DIR"       export EDK_TOOLS_PATH="${PWD}"/BaseTools       source ./edksetup.sh BaseTools       cd "$CLOVERROOT"

they are not crazy. they do that for the same reason. 

 

 

 

Sent from my MI 5s using Tapatalk

 

 

 

 

 

[vector sigma]

1 minute ago, Philip Petev said:

No, they're doing it to override the EDK_TOOLS_PATH auto-detection, made by edksetup.sh and later by BaseTools/BuildEnv.

And why you don't want do the same? All this is just for the first run starting from sratch when you never run ebuild.sh but you want to compile AptioFixPkg and apparently you want Clover and the package to find these drivers. Do you want to not setup it if not detected and BuildEnv.sh (to run a previous configuration) is not yet generated?

 

P.S. The story of the os version is just because of your words, that was working before. It works, but later, only after BuildEnv.sh is loaded. 

 

Bye

[KGP-iMacPro]

@Philip Petev, @vector sigma

 

Fact is that 4.8.8 still results in the same error. At least it employs Xcode 8 toolchain now. 

 

 

 

[Philip Petev]

15 minutes ago, vector sigma said:

And why you don't want do the same? All this is just for the first run starting from sratch when you never run ebuild.sh but you want to compile AptioFixPkg and apparently you want Clover and the package to find these drivers. Do you want to not setup it if not detected and BuildEnv.sh (to run a previous configuration) is not yet generated?

Take a close look at the script. Building all those modules start after both edk2/udk and Clover have already been downloaded.

 

@vector sigma What is really happening on Mojave can be seen only with Build_Clover.command, started with bash -x as prefix. Any discussions without this output are pointless.

Edited June 16, 2018 by Philip Petev

[KGP-iMacPro]

8 minutes ago, Philip Petev said:

@vector sigma What is really happening on Mojave can be seen only with Build_Clover.command, started with bash -x as prefix. Any discussions without this output are pointless.