Jump to content

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

Micky1979

By Micky1979,
in Clover

 Share
2,126 posts in this topic

Recommended Posts

apianti
apianti
Posted
Posted

That doesn't even make sense as a change. sprintf is a standardized function and %llx means long long. Since that is the compiler implementation it has special format specifier checks. No idea why that change was made unless they are explicitly disabling C99 support for GCC when compiling. Ironically, MVSC does not use C99 by default but %llx is always implemented... lol.

Link to comment
Share on other sites
Philip Petev
Philip Petev
Posted
Posted

That doesn't even make sense as a change. sprintf is a standardized function and %llx means long long. Since that is the compiler implementation it has special format specifier checks. No idea why that change was made unless they are explicitly disabling C99 support for GCC when compiling. Ironically, MVSC does not use C99 by default but %llx is always implemented... lol.

That file is brand new, introduced in this commit. Maybe the commit's author hasn't ever heard of any other toolchains/OSes/whatever hahaha... Even so, Xcode hardly could fall into the "GNU C" category as it's the Apple's proprietary toolchain. In term of "GNU C support", that's different story.

Link to comment
Share on other sites
apianti
apianti
Posted
Posted

That file is brand new, introduced in this commit. Maybe the commit's author hasn't ever heard of any other toolchains/OSes/whatever hahaha... Even so, Xcode hardly could fall into the "GNU C" category as it's the Apple's proprietary toolchain. In term of "GNU C support", that's different story.

 

Depending on the Xcode version you might be using GCC, but it eventually switched to clang at some point, which actually has a less restrictive license and is open source and not made by apple. Clang is supposed to be 100% compatible with GCC, it's one of it's top tauted features because it's supposedly also faster. Clang also defines GCC predefined macros so this would affect anything built in Xcode. There is one reason and one reason only to make that change, building with GCC or clang and disabling C99 support. Otherwise, the variable is a UINT64 and every compiler has support for %llx if it supports C99 and some always do, like MSVC. It's just a bad commit, the macro should not be checking for GCC alone but also for C99 being disabled, then it would be the correct preprocessing.

 

EDIT: Like checking __STDC_VERSION__ < 199901L

EDIT2: Forgot Apple clang 4.0 is actually a fork of clang 3.1, so it's kinda made by apple but it's still licensed under BSD, so it might as well be owned by a child in africa because that's not a very broadly enforceable license.

Link to comment
Share on other sites
ErmaC
ErmaC
Posted
Posted

Is there any reason on one of my hacks (Laptop) i have this option

8) Try Clover Configurator Pro.app

But on my other hack (Desktop) that option is not there.

Both machines are running v4.6.2

 

Are you sure in the machine (desktop) you have the app?

I mean if the "Clover Configurator Pro.app" is present than the option will be not displayed...

 

EDIT: or maybe in your settings the key SHOWCCP_ADVERTISE is set to NO

 

ErmaC

  • Like 1
Link to comment
Share on other sites
  • 2 weeks later...
fusion71au
fusion71au
Posted
Posted

Just a request for Build_Clover.command to include an option to build AptioMemoryFix and include AptioMemoryFix.efi in /drivers64UEFI.

At present, I manually build from terminal...

cd ~/src/edk2
git clone https://github.com/vit9696/AptioFixPkg.git
git clone https://github.com/CupertinoNet/CupertinoModulePkg
git clone https://github.com/CupertinoNet/EfiMiscPkg
git clone https://github.com/CupertinoNet/EfiPkg
export NASM_PREFIX="~/src/opt/local/bin/"
source edksetup.sh
make -C BaseTools
touch edk2.ready
build -a X64 -b RELEASE -t XCODE5 -p AptioFixPkg/AptioFixPkg.dsc

---> outputs binary files in ~/src/edk2/Build/AptioFixPkg/RELEASE_XCODE5/X64.

 

Thanks to all the devs involved :)

  • Like 4
Link to comment
Share on other sites
Slice
Slice
Posted
Posted

Hi

 

Clover r4382: I don't no why AptioMemoryFix and AptioInputFix can't be compile (add) with Build_Clover.command v4.6.2? 

 

Thanks

They must be compiled with the same toolset

 

 

~/src/edk2/Build/AptioFixPkg/RELEASE_XCODE5/X64.
  • Like 1
Link to comment
Share on other sites
Matgen84
Matgen84
Posted
Posted

@Slice

 

Sorry but I dont understand what you say with ~/src/edk2/Build/AptioFixPkg/RELEASE_XCODE5/X64.

 

I can compile AptioMemory and AptioInput with vit9696 tool files. ButI I thought to do it with Build_Clover since aptioMemory seems to be in Clover sources. Both files do not appear in Clover installer updater pkg.

 

 

Sorry for my bad english

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

@Slice

 

Sorry but I dont understand what you say with ~/src/edk2/Build/AptioFixPkg/RELEASE_XCODE5/X64.

 

I can compile AptioMemory and AptioInput with vit9696 tool files. ButI I thought to do it with Build_Clover since aptioMemory seems to be in Clover sources. Both files do not appear in Clover installer updater pkg.

 

 

Sorry for my bad english

vit9696 tool compile AptioFix with XCODE5 toolset.

Be sure you are using same toolset when you build Clover.

(I don't use Build_Clover.command v4.6.2 and don't know it).

 

For Clover release I have used XCODE8 toolset for both.

  • Like 3
Link to comment
Share on other sites
fusion71au
fusion71au
Posted
Posted

Hi

 

Clover r4382: I don't no why AptioMemoryFix and AptioInputFix can't be compile (add) with Build_Clover.command v4.6.2? 

 

Thanks

 

The latest commits for AptioFixPkg (jan 17 2018) seem to only build with nasm v2.13.02 in /usr/local/bin.  If I use export NASM_PREFIX="~/src/opt/local/bin/", I now get a nasm build error during the build phase.

 

The following steps worked for me to fix the build...

1)  Delete the old ~/src/edk2/AptioFixPkg folder and reboot the computer.  Clean the edk2 build environment by running Build_Clover.command option 3 (Update Clover + force edk2 update), then exit with option 11.

2)  Install the attached nasm v2.13.02 in /usr/local/bin

sudo cp ~/Downloads/nasm /usr/local/bin/

3)  Then run the following commands to build AptioMemoryFix.efi again...

cd ~/src/edk2
git clone https://github.com/vit9696/AptioFixPkg.git
git clone https://github.com/CupertinoNet/CupertinoModulePkg
git clone https://github.com/CupertinoNet/EfiMiscPkg
git clone https://github.com/CupertinoNet/EfiPkg
source edksetup.sh
make -C BaseTools
touch edk2.ready
build -a X64 -b RELEASE -t XCODE5 -p AptioFixPkg/AptioFixPkg.dsc

---> output binary files in ~/src/edk2/Build/AptioFixPkg/RELEASE_XCODE5/X64

 

4)  Replace OsxAptioFix3Drv-64.efi in ~/src/edk2/Clover/CloverPackage/CloverV2/drivers-Off/drivers64UEFI with AptioMemoryFix.efi.

 

Slightly modified @vit9696's build script (attached Build_AptioFixPkg.sh) so it uses existing ~/src/edk2  ---> output to ~/src/edk2/Clover/CloverPackage/CloverV2/drivers-Off/drivers64UEFI.

 

Edit:  Build_Clover.command v4.6.4 now automatically compiles AptioMemoryFix.efi when using XCODE5 toolchain.  Thanks @Micky1979 and @Vit9696 :).

nasm.zip

Compiled AptioFixPkg.zip

Build_AptioFixPkg.sh.zip

  • Like 2
Link to comment
Share on other sites
Pavo
Pavo
Posted
Posted

The latest commits for AptioFixPkg (jan 17 2018) seem to only build with nasm v2.13.02 in /usr/local/bin.  If I use export NASM_PREFIX="~/src/opt/local/bin/", I now get a nasm build error during the build phase.

 

The following steps worked for me to fix the build...

1)  Delete the old ~/src/edk2/AptioFixPkg folder and reboot the computer.  Clean the edk2 build environment by running Build_Clover.command option 3 (Update Clover + force edk2 update), then exit with option 11.

2)  Install the attached nasm v2.13.02 in /usr/local/bin

sudo cp ~/Downloads/nasm /usr/local/bin/

3)  Then run the following commands to build AptioMemoryFix.efi again...

cd ~/src/edk2
git clone https://github.com/vit9696/AptioFixPkg.git
git clone https://github.com/CupertinoNet/CupertinoModulePkg
git clone https://github.com/CupertinoNet/EfiMiscPkg
git clone https://github.com/CupertinoNet/EfiPkg
source edksetup.sh
make -C BaseTools
touch edk2.ready
build -a X64 -b RELEASE -t XCODE5 -p AptioFixPkg/AptioFixPkg.dsc

---> output binary files in ~/src/edk2/Build/AptioFixPkg/RELEASE_XCODE5/X64

 

4)  Replace OsxAptioFix3Drv-64.efi in ~/src/edk2/Clover/CloverPackage/CloverV2/drivers-Off/drivers64UEFI with AptioMemoryFix.efi.

Or you could just use the script I made that does everything automated for you.

AptioMemory_Builder.sh.zip

  • Like 3
Link to comment
Share on other sites
Sherlocks
Sherlocks
Posted
Posted

I made clover package r4390. I already have OsxFatbinary-64 until install r4390. After install r4390, Osxfatbinary-64 was removed automatically. I didn't touch any additional option to install extra binary. Old clover package is no problem. Just happen on latest clover package.

 

Thanks in advance

 

나의 LG-F800S 의 Tapatalk에서 보냄

Link to comment
Share on other sites
Slice
Slice
Posted
Posted

I made clover package r4390. I already have OsFatbinary-64 until install r4390. After install r4390, osfatbinary-64 was removed. I didn't touch any additional option to install extra binary. Old clover package is no problem. Just happen on latest clover package.

 

Thansk in advance

 

나의 LG-F800S 의 Tapatalk에서 보냄

OsxFatBinary.efi is optional now. It is needed only for systems previous to 10.8.

If you want to install it check the driver in Clover package.

Link to comment
Share on other sites
 Share
Go to topic listing
×
×
  • Create New...