Open kencu opened 6 years ago
I'm still not wild about the std::log2
changes, because the code as written compiles fine on 10.4 and it's a change I have to carry forward for future OTS updates. I'd rather see that made as a change to the 10.5 SDK itself, since the code compiles on every other system except 10.5.
True enough. Difficult for me to change my 10.5 SDK though as I need that to be as stock as possible for building other software, MacPorts, etc.
I could try to backport the gcc7 10.5 SDK fix into gcc48 through gcc6. That might be possible.
If not that, I wonder if we might get away with one single #define in one common header. Perhaps something like this might work?
--TEST-FOR-10.5-&&-GCC-LESS-THAN-7
#define std::log2(x) log2(x)
--END-TEST
If not that, I wonder if we might get away with one single #define in one common header. Perhaps something like this might work?
--TEST-FOR-10.5-&&-GCC-LESS-THAN-7 #define std::log2(x) log2(x) --END-TEST
I'd be willing to accept that in the right place (i.e., under our control, and unlikely to be upended by future need to update the library). The problem with OTS is it gets updated a lot since it's a security component, essentially, so I'd rather not add changes I don't need/want to port forward for the core build.
I wish I better understood exactly why & how gcc48 builds it correctly against the 10.4 SDK on Tiger, but not against the 10.4 SDK on Leopard. Something is slinking in somehow...
Anyway, doesn't much matter I guess. I will work on a "one liner" and see how that can fit into the mix.
Thanks for the extra efforts to broaden out the build / appeal / usage of TFF. The fact that this exists at all and the labour involved is not lost on any of us, and there is no intention to make any of your much-appreciated work any harder than it is!
I know you don't like the patch - this is why it is the still "uncommittable" patchs. Point is, it is not a 10.5 only patch: I need it on 10.6 too It works "for you" and we noticed there are still some issues with the build environments. What amazes me is that it looks that your environment is somehow "more modern" since log2 moved into std:: Yet, I have all stuff updated to latest macports... and you not!
I'd like to find where this std::log2 difference is coming in between Tiger and Leopard.
The libgcc <cmath>
header installed on 10.4 and on 10.5 are identical.
The built-in gcc-48 defines are nearly identical on 10.4 and 10.5. There are minor changes in the following:
defined by default on Leopard but not Tiger:
#define __VEC__ 10206
#define __ALTIVEC__ 1
#define __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ 1058
#define __APPLE_ALTIVEC__ 1
defined on Tiger but not Leopard:
#define __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ 1040
Both builds are using the 10.4u SDK.
@kencu : When building on Tiger/x86 can you do without the patch: that is, on your up-to-date Tiger system can you reproduce what Cameron has on 10.4/PPC with a slightly older compiler?
I hope I can soon get my 10.5/PPC environment working, that could be a cross-test.
I suppose it has to do with some "define" enabling different versions in the headers, with different namespaces, bout couldn't make it out yet.
gcc7+ works (the math issue was fixed there). Looks like it's not too hard to force gcc7 for this part of the build using a Makefile.in
in gfx/ots/src
.
Alternately you can force gcc-4.8 to use the std::math functions with some trickery, forcing a define and adding some missing definitions to the mix. It ain't pretty, but it works.
See:
https://trac.macports.org/ticket/54820
and
https://github.com/macports/macports-ports/commit/78896778109ce1f25a02c4c167d1e6d6ddf33d4d
I am going to try backporting the gcc7 fix into gcc6 and then gcc48.
I have not tried to build TFF on my G5 yet, but I have experienced lots of problems with macports builds on my G5 (+universal
for archs ppc
and ppc64
) with any ld64
other than +ld64_97
, so that prerequisite is not new to me.
I cannot remember details any more, but the few notes I have taken report that +ld64_127
breaks ppc64
compilations when building gcc-mp-*
.
One problem with +ld64_97
is that that linker does not fully support branch islands, so for large executables it is likely to fail with a message like ld: bl out of range
.
I noted the same thing -- there is a patch that appears to fix the branch islands problem in this version of ld64-97
https://github.com/kencu/TigerPorts/tree/master/devel/ld64 (I should probably push this into MacPorts main repo, if Jeremy would accept it.)
@kencu: Thanks for this! Just looking at the contents of the island patch makes it look definitely push-worthy to me.
I am going to try backporting the gcc7 fix into gcc6 and then gcc48.
I did that - and tested it and with gcc48 it compiles now. @classilla what exact version of gcc48 are you using? I am wondering if you backported your patch or if this is some regression inside the gcc48 series. I would like to ask upstream to fix that (improbable) by accepting the patch
all versions of gcc do not show the std::math deletions on 10.4.
They only show up on 10.5 and 10.6. I haven't been able to figure out exactly why that is.
This is getting pretty dated, but doesn't the problem lie in math.h?
Missing C99 math funcs in leopard from the GCC bug:
> test.cxx:53:21: error: 'llrint' was not declared in this scope
> llrint(0.0);
> ^
> test.cxx:54:23: error: 'llrintf' was not declared in this scope
> llrintf(0.0f);
> ^
> test.cxx:55:23: error: 'llrintl' was not declared in this scope
> llrintl(0.0l);
> ^
> test.cxx:56:22: error: 'llround' was not declared in this scope
> llround(0.0);
> ^
> test.cxx:57:24: error: 'llroundf' was not declared in this scope
> llroundf(0.0f);
> ^
> test.cxx:58:24: error: 'llroundl' was not declared in this scope
> llroundl(0.0l);
> ^
When I tested they work as normal with C99 so it's only C++11.
math.h
in tiger:
https://opensource.apple.com/source/Libm/Libm-213/ppc.subproj/math.h.auto.html
math.h
in leopard:
https://opensource.apple.com/source/Libm/Libm-292.4/Source/PowerPC/math.h.auto.html
In leopard, every long long
type function mentioned above is wrapped in #if ( defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L ) || ! defined( __STRICT_ANSI__ ) || ! defined( __GNUC__ )
. The C99 math detection test must be separate for C++, and the #ifdef guard wrapping the ll* functions prototypes doesn't doesn't look C++11 friendly.
Simple-minded approach would be to add a case for c++11 in there, but without modification of system headers, not sure.
Yes, that's pretty much it. The by-case fix works just fine, indeed :)
@classilla I am trying to build with gcc6 on 10.5.8, and it fails on this:
gmake[8]: Entering directory '/Users/svacchanda/tenfourfox/obj-ff-dbg/intl/icu/target/data'
gmake[8]: Leaving directory '/Users/svacchanda/tenfourfox/obj-ff-dbg/intl/icu/target/data'
generating out/tmp/res_index.txt (list of installed locales)
generating out/tmp/curr/res_index.txt (list of installed currency name locales)
generating out/tmp/lang/res_index.txt (list of installed language name locales)
./out/tmp/lang/res_index.txt:3: warning: Encountered empty array
generating out/tmp/region/res_index.txt (list of installed region name locales)
./out/tmp/region/res_index.txt:3: warning: Encountered empty array
generating out/tmp/zone/res_index.txt (list of installed time zone name locales)
generating out/tmp/unit/res_index.txt (list of installed time zone name locales)
./out/tmp/unit/res_index.txt:3: warning: Encountered empty array
generating out/tmp/coll/res_index.txt (list of installed collation locales)
generating out/tmp/brkitr/res_index.txt (list of installed break locales)
./out/tmp/brkitr/res_index.txt:3: warning: Encountered empty array
generating out/tmp/rbnf/res_index.txt (list of installed RBNF locales)
./out/tmp/rbnf/res_index.txt:3: warning: Encountered empty array
ALL_CFU_SOURCE: /Users/svacchanda/tenfourfox/intl/icu/source/data/unidata/confusables.txt /Users/svacchanda/tenfourfox/intl/icu/source/data/unidata/confusablesWholeScript.txt
CFU_FILES: ./out/build/icudt56b/confusables.cfu
CFU_FILES_SHORT: confusables.cfu
gencfu writes dummy out/build/icudt56b/confusables.cfu because of UCONFIG_NO_REGULAR_EXPRESSIONS and/or UCONFIG_NO_NORMALIZATION and/or UCONFIG_NO_FILE_IO, see uconfig.h
generating out/tmp/icudata.lst (list of data files)
pkgdata: /opt/svacchanda/gcc6/bin/gcc -flax-vector-conversions -O3 -mcpu=G5 -m32 -falign-loops=32 -falign-functions=32 -falign-labels=32 -falign-jumps=32 -mmfcrf -mpowerpc-gpopt -read_only_relocs suppress -force_cpusubtype_ALL -mdynamic-no-pic -D_PPC970_ -DU_ATTRIBUTE_DEPRECATED= -DU_USING_ICU_NAMESPACE=0 -DU_NO_DEFAULT_INCLUDE_UTF_HEADERS=1 -DUCONFIG_NO_LEGACY_CONVERSION -DUCONFIG_NO_TRANSLITERATION -DUCONFIG_NO_REGULAR_EXPRESSIONS -DUCONFIG_NO_BREAK_ITERATION -DU_CHARSET_IS_UTF8 -I/Users/svacchanda/tenfourfox/intl/icu/source/common -I/Users/svacchanda/tenfourfox/intl/icu/source/i18n -DU_HAVE_ATOMIC=1 -DU_HAVE_TIMEZONE=0 -fPIC -Wall -Wempty-body -Wpointer-to-int-cast -Wsign-compare -Wtype-limits -Wno-unused -Wcast-align -isysroot /Developer/SDKs/MacOSX10.4u.sdk -std=gnu99 -fno-strict-aliasing -fno-exceptions -fno-math-errno -pthread -DNO_X11 -pipe -gdwarf-2 -UDEBUG -DNDEBUG -O3 -fno-common -c -I/Users/svacchanda/tenfourfox/intl/icu/source/common -I../common -dynamic -o ./out/tmp/icudt56b_dat.o ./out/tmp/icudt56b_dat.S
cc1: warning: ‘-mdynamic-no-pic’ overrides ‘-fpic’, ‘-fPIC’, ‘-fpie’ or ‘-fPIE’
pkgdata: /opt/svacchanda/gcc6/bin/gcc -flax-vector-conversions -O3 -mcpu=G5 -m32 -falign-loops=32 -falign-functions=32 -falign-labels=32 -falign-jumps=32 -mmfcrf -mpowerpc-gpopt -read_only_relocs suppress -force_cpusubtype_ALL -mdynamic-no-pic -D_PPC970_ -dynamiclib -dynamic -fPIC -Wall -Wempty-body -Wpointer-to-int-cast -Wsign-compare -Wtype-limits -Wno-unused -Wcast-align -isysroot /Developer/SDKs/MacOSX10.4u.sdk -std=gnu99 -fno-strict-aliasing -fno-exceptions -fno-math-errno -pthread -DNO_X11 -pipe -gdwarf-2 -UDEBUG -DNDEBUG -O3 -framework ExceptionHandling -framework Cocoa -lobjc -framework ApplicationServices -o ../lib/libicudata.56.2.dylib ./out/tmp/icudt56b_dat.o -Wl,-compatibility_version -Wl,56 -Wl,-current_version -Wl,56.2 -install_name @executable_path/libicudata.56.dylib
warning: no debug symbols in executable (-arch ppc)
pkgdata: cd ../lib/ && rm -f libicudata.56.dylib && ln -s libicudata.56.2.dylib libicudata.56.dylib
pkgdata: cd ../lib/ && rm -f libicudata.dylib && ln -s libicudata.56.2.dylib libicudata.dylib
gmake[7]: Leaving directory '/Users/svacchanda/tenfourfox/obj-ff-dbg/intl/icu/target/data'
gmake[7]: Entering directory '/Users/svacchanda/tenfourfox/obj-ff-dbg/intl/icu/target'
Note: rebuild with "gmake VERBOSE=1 all-local" to show all compiler parameters.
gmake[7]: Leaving directory '/Users/svacchanda/tenfourfox/obj-ff-dbg/intl/icu/target'
gmake[6]: Leaving directory '/Users/svacchanda/tenfourfox/obj-ff-dbg/intl/icu/target'
gmake[5]: Leaving directory '/Users/svacchanda/tenfourfox/obj-ff-dbg/config/external/icu'
gmake[4]: Leaving directory '/Users/svacchanda/tenfourfox/obj-ff-dbg'
gmake[3]: *** [/Users/svacchanda/tenfourfox/config/recurse.mk:33: compile] Error 2
gmake[3]: Leaving directory '/Users/svacchanda/tenfourfox/obj-ff-dbg'
gmake[2]: *** [/Users/svacchanda/tenfourfox/config/rules.mk:547: default] Error 2
gmake[2]: Leaving directory '/Users/svacchanda/tenfourfox/obj-ff-dbg'
gmake[1]: *** [/Users/svacchanda/tenfourfox/client.mk:396: realbuild] Error 2
gmake[1]: Leaving directory '/Users/svacchanda/tenfourfox'
gmake: *** [client.mk:171: build] Error 2
At present, there are two hiccups with building TFF on LeopardPPC, for anyone who is interested in this.
Follow all instructions as outlined to build TFF on PPC Tiger as listed here https://github.com/classilla/tenfourfox/wiki/HowToBuildFPR.
Then you have to fix a small linker issue.
gcc48
from MacPorts is hard-coded to use the linker (and most other bits) installed in ${prefix}/bin (usually that's /opt/local/bin/ld). When building on 10.5 against the 10.4 SDK, the only linker that works (I believe) isld64-97
. So you have installld64-97
from MacPorts. Now it may be possible to code into the mozconfig that you want to use that linker, but that didn't work for me when I tried various ways.What does work is to have MacPorts use it as the default linker by installing
ld64
with this variantld64 +ld64_97
.ld64
is a port that just installs a bunch of symlinks to to the version of ld that you want to use, as specified by the variant you selected. Note thatld64-97
means you need to use the variant+ld64_97
. The dash and underscore are important.After that, you need to compensate for a slight difference in the way the math headers work on Leopard vs. Tiger. The details are here https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79017 and the issue apparently disappears as of
gcc7
but in essence, on earlier gcc versions, a small patch takes care of it.After that, TenFourFox builds through and runs perfectly well on Leopard, and you can run some tests, try things out, etc. That particular TenFourFox will not run on Tiger as Cameron has previously described because the underpinnings are specific to Leopard, but it's easy enough to fix that as he points out in the original build post.
When you're done building TenFourFox, you probably will want to change your default linker back to
ld64-127
by installingld64 +ld64_127
.