PPC 64bit library status?
For what are probably misguided reasons I am trying to build Apple style compilers which include gfortran, libffi and libobjc. This was not a particular problem with the latest apple-ppc-branch sources (apple-ppc-5013) until I got MacOS X 10.4 Tiger yesterday. On Darwin8/MacOS X 10.4 the Apple gcc build includes both 32 and 64 bit versions of libgcc, libiberty and libstdc++. When I alter the build_gcc script and the configure files to build gfortran, libffi and libobjc, the build tries to make 64 bit versions of libgfortran, libgfortranbegin, libffi and libobjc-gnu. There are a number of problems: 1. Since I am using a PPC7455 based computer 64bit executables won't run and the 64 bit libraries are effectively cross compilations. So the configure scripts need the same APPLE LOCAL mods used in libstdc+ + to avoid testing in the configure script whether the compiler can build executables. (with the -m64 flag the executables are built but they won't run). This would not be an issue on a PPC970(G5) cpu. 2. libgfortran.h line 63 defines int8_t. This is already defined in / usr/lib/ppc/types.h. So I think the libgfortran.h define needs to be conditional on _INT8_H. Even if the libraries build, will libffi or libobjc work on 64 bit PPC Since I don't have access to a 64 bit PPC machine I cannot test this. There is an even murkier question about what happens with Darwin 8 on x86. Bill Northcott
Re: PPC 64bit library status?
On 01/05/2005, at 1:11 AM, Andrew Pinski wrote: Even if the libraries build, will libffi or libobjc work on 64 bit PPC Since I don't have access to a 64 bit PPC machine I cannot test this. There was some talk about this earlier this year and then the support for building the 64bit libraries on darwin was turned off for both the 4.0.0 release and on the mainline. That much was sort of obvious. However, if they are enabled in the build, libobjc and libgfortran do build. Are they likely to be functional? Libffi does not build using the -m64 flag on the compiler. Note why again are you using Apple's branch. It does not get all fixes which the 4.0 release branch will get. Basically my logic is fairly simple. If I use Apple's OS, I feel happier using their compiler. While that creates some problems, it avoids others like the restFP,savFP issue. The code I am using was synced to the release gcc-4.0.0 on 20 April. So it is not that out of date. Bill Northcott
spec failure: unrecognized spec option ...
I have been building gcc-4.0.0 from Apple sources with tags in the
apple-ppc-5000 series.
I was getting lots of messages like this "spec failure: unrecognized
spec option 'Q'"
I notice that APPLE LOCAL tagged changes seem to turn spec warnings
on. Presumably they are off by default.
I amended /usr/lib/gcc/powerpc-apple-darwin8/4.0.0/specs line 26 and
27 from:
*cpp_unique_options:
%yC%{C|CC:%{!E:%eGCC does not support -C or -CC without -E}} %{!
traditional:%{!ftraditional:%{!traditional-cpp:%Q}}} %{!Q:-quiet} %
{nostdinc*} %{C} %{CC} %{v} %{I*&F*} %{P} %I %{MD:-MD %{!o:%b.d}%{o*:
%.d%*}} %{MMD:-MMD %{!o:%b.d}%{o*:%.d%*}} %{M} %{MM} %{MF*} %{MG} %
{MP} %{MQ*} %{MT*} %{!E:%{!M:%{!MM:%{MD|MMD:%{o*:-MQ %*} %
{trigraphs} %{remap} %{g3:-dD} %{H} %C %{D*&U*&A*} %{i*} %Z %i %
{fmudflap:-D_MUDFLAP -include mf-runtime.h} %{fmudflapth:-D_MUDFLAP -
D_MUDFLAPTH -include mf-runtime.h} %{E|M|MM:%W{o*}}
to:
*cpp_unique_options:
%yC%{C|CC:%{!E:%eGCC does not support -C or -CC without -E}} %{!Q:-
quiet} %{nostdinc*} %{C} %{CC} %{v} %{I*&F*} %{P} %I %{MD:-MD %{!o:%
b.d}%{o*:%.d%*}} %{MMD:-MMD %{!o:%b.d}%{o*:%.d%*}} %{M} %{MM} %{MF*} %
{MG} %{MP} %{MQ*} %{MT*} %{!E:%{!M:%{!MM:%{MD|MMD:%{o*:-MQ %*} %
{trigraphs} %{remap} %{g3:-dD} %{H} %C %{D*&U*&A*} %{i*} %Z %i %
{fmudflap:-D_MUDFLAP -include mf-runtime.h} %{fmudflapth:-D_MUDFLAP -
D_MUDFLAPTH -include mf-runtime.h} %{E|M|MM:%W{o*}}
All the warnings stopped.
I have no idea what is going on here. Can someone please give me
some clues.
Bill Northcott
Re: spec failure: unrecognized spec option ...
On 20/05/2005, at 3:51 AM, Mike Stump wrote: I have been building gcc-4.0.0 from Apple sources with tags in the apple-ppc-5000 series. I was getting lots of messages like this "spec failure: unrecognized spec option 'Q'" I amended /usr/lib/gcc/powerpc-apple-darwin8/4.0.0/specs rm -rf /usr/lib/gcc/*/4.0.0/specs Clearly that is the surgical solution, but what is the file there for? I have now realised that it is not generated as part of the compiler build process. In fact it is one of two files in Apple Xcode gcc-4.0 package which is not derived from the source code. The other is "/ Library/Application Support/Xcode/Specifications/GCC 4.0.xcspec" I now realise the warnings arise because the specs file is from a different compiler. Presumably these files serve some purpose. How do they affect the operation of the compiler? Bill Northcott
Re: spec failure: unrecognized spec option ...
On 21/05/2005, at 4:02 AM, Mike Stump wrote: I have now realised that it is not generated as part of the compiler build process. It used to be. Presumably these files serve some purpose. How do they affect the operation of the compiler? For the specs file, negatively. For the other, none, as it isn't consulted by the compiler. Xcode might use it however. So I understand that the specs file was a useless appendage in compilers with apple-gcc-40xx tags such as the standard Xcode 2.0 gcc-4. It is not built by apple-ppc-50xx tags. It should be removed when installing a 50xx compiler. Thanks for the help Bill Northcott
Re: could gfortran be tested on Darwin regress builds of 4.1?
On 30/07/2005, at 1:06 AM, Jack Howarth wrote: Well the gcc4.info for the package containing gfortran in fink has... Depends: gmp-shlibs (>= 4.1.3-11), cctools (>= 576-1) | odcctools (>= 576-200503 27), %N-shlibs, libiconv BuildDepends: gmp (>= 4.1.3-11), libiconv-dev which is a tad confusing since I guess it implies that cctools isn't needed to build gcc4/gfortran but is needed to use it. That seems weird since to build it and do a make check is to effectively use it. I built a working (builds functioning R and Octave) gfortran with Apple's gcc 4 on MacOS X 10.4.1 (Darwin 8.1). The only thing I needed to add was gmp, which built from the source without problems. The cc-tools in Darwin 8 is 590. So I think it would be a bad idea to install 576! If I get time, I will try the current code. Bill Northcott
Darwin cross-compiler build failures on ppc MacOSX/Darwin
I am trying to build a universal APPLE gcc on a MacOS PPC system, because I want to tweak it to add a couple extra features. The build fails as already described here: http://www.cocoabuilder.com/archive/message/cocoa/2005/6/24/139961 The problem seems to be around line 1626 of gcc/configure.ac in both Apple and FSF versions where the following appears: if test x$host != x$target then CROSS="-DCROSS_COMPILE" ALL=all.cross SYSTEM_HEADER_DIR='$(CROSS_SYSTEM_HEADER_DIR)' case "$host","$target" in # Darwin crosses can use the host system's libraries and headers, # because of the fat library support. Of course, it must be the # same version of Darwin on both sides. Allow the user to # just say --target=foo-darwin without a version number to mean # "the version on this system". *-*-darwin*,*-*-darwin*) hostos=`echo $host | sed 's/.*-darwin/darwin/'` targetos=`echo $target | sed 's/.*-darwin/darwin/'` if test $hostos = $targetos -o $targetos = darwin ; then CROSS= SYSTEM_HEADER_DIR='$(NATIVE_SYSTEM_HEADER_DIR)' with_headers=yes fi ;; i?86-*-*,x86_64-*-* \ | powerpc*-*-*,powerpc64*-*-*) CROSS="$CROSS -DNATIVE_CROSS" ;; esac elif test "x$TARGET_SYSTEM_ROOT" != x; then As far as I can see, the assumption of the test is currently incorrect and the logic of the test is flawed. The assumption is incorrect because, MacOS PPC systems do not have i386 code in their system libraries, only ppc and ppc64. MacOS Intel system have three way fat libraries with i386, ppc and ppc64 code. The logic seems to me to be flawed first because it confuses the build os with the host os on which the compiler being built is expected to run. Secondly it ignores what comes after "darwin" in the host and target names. As luck would have it, an FSF build seems the invoke configure in gcc with host=ppc-apple-darwin8.6.0 and target=i386-apple-darwin8. The test if test $hostos = $targetos -o $targetos = darwin ; then fails and the build succeeds. In the Apple build host gets set to ppc-apple-darwin8. So the test succeeds and the build fails because of the missing i386 code in the system libraries. There is similar code in the configure script of libstdc++. None of this is a problem on MacOS X Intel. The cross-compilers build without problems on an Intel Mac. This has also been reported by someone trying to use the SDKs to build a cross compiler on Linux which targeted i386 Darwin, I am afraid I have lost the reference. Cheers Bill Northcott
Re: Darwin cross-compiler build failures on ppc MacOSX/Darwin
On 14/06/2006, at 5:15 AM, Mike Stump wrote: None of this is a problem on MacOS X Intel. The cross-compilers build without problems on an Intel Mac. Well, apparently one solution is to fatten your system. My attempts to do that just resulted in a system that would not boot :-( Fortunately, I tried it on a spare disk. The other might be to try: x86-*-darwin*,*-*-darwin*) instead, and then use --with-sysroot=/. I have done something like that already. Basically breaking the configure test and adding --with-sysroot= to the CONFIGFLAGS definition in build-gcc. This allowed the powerpc-i686 build to go through. [ this list is for people that want to roll up their sleeves and fix their own problem. If you want us to fix it for you, just file a PR. :-) ] I am trying. Currently the cross-hosted compiler build still breaks, which seems to be an issue with the SDK. The link breaks like this: /usr/bin/ld: warning fat file: /usr/lib/system/libmathCommon.A.dylib does not contain an architecture that matches the specified -arch flag: i386 (file ignored) /usr/bin/ld: warning multiple definitions of symbol _strncmp ../libiberty/libiberty.a(strncmp.o) definition of _strncmp in section (__TEXT,__text) /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libSystem.dylib(strncmp.So) definition of _strncmp /usr/bin/ld: Undefined symbols: _fegetround referenced from libSystem expected to be defined in /usr/ lib/system/libmathCommon.A.dylib collect2: ld returned 1 exit status make[2]: *** [makedepend] Error 1 make[1]: *** [all-libcpp] Error 2 + exit 1 This would seem to be because libSystem.B.dylib references the system's libmathCommon. billn% otool -L /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/ libSystem.B.dylib /Developer/SDKs/MacOSX10.4u.sdk/usr/lib/libSystem.B.dylib: /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 88.1.3) /usr/lib/system/libmathCommon.A.dylib (compatibility version 1.0.0, current version 210.0.0) This cannot be changed with install_name_tool because libSystem.B.dylib is a stub library. Any suggestions? Does the -isysroot compiler flag fix this sort of issue? It does not seem to be used in the gcc build. Bill
Re: Darwin cross-compiler build failures on ppc MacOSX/Darwin
On 14/06/2006, at 10:47 AM, Mike Stump wrote: Any suggestions? Does the -isysroot compiler flag fix this sort of issue? It does not seem to be used in the gcc build. I'd expect it might. Run with -v and see if isysroot is given to ld. If not, add -Wl,-isysroot=... to pass it down to ld. In later compilers, we do this automagically, given -isysroot. I have written this up on the problem report. -isysroot causes -isyslibroot to be given to ld. So you cannot add - Wl,-isyslibroot or the links fail with 'syslibroot multiply defined' The problem is that CFLAGS are not passed into the build of libgcc. So unless -DCROSS_COMPILE is in the option list for the compiles within libgcc --with-sysroot (TARGET_SYSTEM_ROOT) is ignored and libgcc link fails because there is no code in the linked libSystem library for the target architecture. So the configure script is the basic cause of the problem, because it assumes the system libraries are fat when they are not. I can't see how it hurts to test for fat libraries instead of assuming their presence. Bill
Bootstrap of gcc-3.4.3 on Tru64 5.1B PR16787
I have now tested the -ieee flag. So this is a documentation error, because the vital option is not mentioned in the host specific note. I have added a suggested documentation change to PR16787. It would be good if someone could fix the documentation. Bill Northcott On 10/02/2005, at 12:56 PM, Andrew Pinski wrote: It is more likely to be fixed if a bug report is filed. Or you could try submitting a formal patch to the gcc-patches list, but this is much more work, and requires follow up. There is already a bug report, PR 16787. But the way to compile on Tru64 is to use -ieee so that we get IEEE floating points with NANs.
