Re: UNIVERSAL_ARCHFLAGS
> Why would a universal library be incompatible with building for a single > arch? What is the actual failing command? > > I went through the old travis builds again. it was because I added arch flags to a variable named `CFLAFS` which being a typo never got added to CFLAGS. The issue is now resolved when using -s flag with ar. [1] [1] https://travis-ci.org/macports/macports-base/builds/648249435?utm_source=github_status_medium=notification Thanks, Mihir
Re: UNIVERSAL_ARCHFLAGS
On 2020-2-10 09:44 , Mihir Luthra wrote: > Hi, > > Creating a static library from fat object files works fine as long as > there's an index. That means using the -s option with ar, or running > ranlib after creation. The usual command is "ar crs .a *.o". > > > I was making a static lib that can be used by both darwintracelib1.0 and > pextlib1.0. > > darwintracelib1.0 uses UNIVERSAL_ARCHFLAGS in its build and pextlib1.0 > doesn't. > > So, on Catalina, the build works as UNIVERSAL_ARCHFLAGS resolve to > x86_64 only. > But on 10.13, build fails as library is incompatible, Why would a universal library be incompatible with building for a single arch? What is the actual failing command? - Josh
Re: UNIVERSAL_ARCHFLAGS
Hi, Creating a static library from fat object files works fine as long as > there's an index. That means using the -s option with ar, or running > ranlib after creation. The usual command is "ar crs .a *.o". > > I was making a static lib that can be used by both darwintracelib1.0 and pextlib1.0. darwintracelib1.0 uses UNIVERSAL_ARCHFLAGS in its build and pextlib1.0 doesn't. So, on Catalina, the build works as UNIVERSAL_ARCHFLAGS resolve to x86_64 only. But on 10.13, build fails as library is incompatible, Probably, for that reason sip_copy_proc.c is copied from pextlib1.0 to darwintracelib1.0 so that it is again separately compiled as per darwintracelib1.0 flags. I was thinking to add UNIVERSAL_ARCHFLAGS to pextlib1.0's build as well so that the static lib is compatible with both. I don't see what would be the issue if pextlib1.0 gets built for multiple -archs. Will it be okay to do so? MIhir
Re: UNIVERSAL_ARCHFLAGS
On 2020-2-9 00:46 , Mihir Luthra wrote: > Hi, > > There is something I am not able to understand in base. > > Looking into aclocal.m4, based on the version of macOS, supported archs > are being determined. Based on them -arch flags are constructed. > > For example, if using macos 10.13, > UNIVERSAL_ARCHFLAGS= -arch x86_64 -arch i386. > > Would adding them to CFLAGS and compiling mean that the result would be > compatible with both x86_64 and i386? Or it it overriding the previous flag? With clang and Apple gcc, -arch flags are cumulative. > Doesn't it automatically default to the arch as per the os version > without using -arch flags? The default is up to the compiler, but sure. > As for what it makes sense, I assume its producing library to be > compatible with both x86_64 and i386. It is being used in > darwintracelib1.0 and darwintracelib needs to be compatible with all > supported archs on OS as it is getting injected into the installation. > How important is it to support i386 as for now? Will it be okay if i386 > support is withdrawn and -arch is specified as x86_64 only? It's important to have on all versions older than 10.14. > Is there anyway to produce static libraries like this? > The best option I find is libtool -static -arch_only but that > works only if it's a single argument. Creating a static library from fat object files works fine as long as there's an index. That means using the -s option with ar, or running ranlib after creation. The usual command is "ar crs .a *.o". - Josh
UNIVERSAL_ARCHFLAGS
Hi, There is something I am not able to understand in base. Looking into aclocal.m4, based on the version of macOS, supported archs are being determined. Based on them -arch flags are constructed. For example, if using macos 10.13, UNIVERSAL_ARCHFLAGS= -arch x86_64 -arch i386. Would adding them to CFLAGS and compiling mean that the result would be compatible with both x86_64 and i386? Or it it overriding the previous flag? Doesn't it automatically default to the arch as per the os version without using -arch flags? As for what it makes sense, I assume its producing library to be compatible with both x86_64 and i386. It is being used in darwintracelib1.0 and darwintracelib needs to be compatible with all supported archs on OS as it is getting injected into the installation. How important is it to support i386 as for now? Will it be okay if i386 support is withdrawn and -arch is specified as x86_64 only? Is there anyway to produce static libraries like this? The best option I find is libtool -static -arch_only but that works only if it's a single argument. Thanks, Mihir
