Hi Stefano,
1. Although you provided quite a lot of information, I am making some inferences from the data, so we might need more than one iteration.
2. I am not subscribed to this list, please CC me in any reply directly
> On 12 Mar 2017, at 17:47, ssbb <effed3s at gmail dot com> wrote:
> As subject say, building is ok, but some points arise, so asking some (maybe elementary) question to experts:
>
> Gcc-4.9.4 on PowerMac-G5 OSX-10.5.8, using apple gcc-4.2.1, build fine, test and install:
> Included in gcc source tree the required libraries: gmp-4.3.2, mpfr-2.4.2, mpc-0.8.1, and isl-0.12.2, cloog-0.18.1 plus libiconv-1.15.
> Configured with:
> ------------------------
> export MAC=powerpc-apple-darwin9.8.0
> ../gcc-4.9.4/configure --prefix=/usr/local/gcc-4.9.4 --disable-nls --enable-languages=c,c++ --build=$MAC --host=$MAC --target=$MAC
> ------------------------
>
> With otool i examine the executables and find:
> ------------------------
> $ otool -L /usr/local/gcc-4.9.4/bin/c++
> ./c++:
> /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.7)
> ------------------------
> Same is for all others exec in bin/
>
> [QUESTION]: libiconv included in sourcetree was build, but later ignored at link time in favor of system libiconv?
The system linker ld64 [at least at the 85.2.1 version from XCode 3.1.4] will prefer a shared library if it finds one (even if there is a convenience library of the same name first on the link line).
There is a reason for this - to do with the different model for symbol resolution in the Mach-O toolchain (c.f. the ELF ones, for example). This has some advantages (only need to present libraries once) and some gotchas (the shlib will be found over the convenience one). Recent versions of ld64 have more controls over this, but you’d need to use my port of the PPC stuff (since that was dropped from ld64 around XCode 3.2.x).
/usr/lib and /usr/local/lib are added to the linker search path by convention - so that shared libraries found there will be used in preference to any convenience library on the command line.
If you want to force the use of libiconv.a then the method is to replace -liconv with /path/to/libiconv.a in the link line (this is what GCC does when we invoke -static-xxxxx on the command line).
If at some point you built and installed a “standard” GMP / MPFR configuration, then that would be installed in /usr/local and would have shared libs - so ld64 will prefer that.
Looking at what you have below I think that what you’re seeing is explained by the comments above.
FWIW:
a) I don’t generally try to overide the system libiconv (but accept that there could be some reason you might want to - just be careful of interactions between things built one way or another)
b) it’s quite a good idea to bootstrap GMP and friends along with the compiler - so just symlink new enough sources into the GCC source tree.
c) When I don’t bootstrap GMP &co with the compiler, then I build them as convenience libs (IMO it’s better to have the compiler with no deps. on external shlibs except those installed on the system itself).
Note that if you have pre-existing installations of shared versions of GMP etc. in /usr/local you’ll most certainly need to uninstall them (or use them).
Of course, that’s up to you to decide on the basis of your requirements.
Anyway, hopefully, that helps explain what you see,
Iain
> Looking more with otools:
> ------------------------
> $ otool -L /usr/local/gcc-4.9.4/libexec/gcc/powerpc-apple-darwin9.8.0/4.9.4/cc1
> /usr/local/gcc-4.9.4/libexec/gcc/powerpc-apple-darwin9.8.0/4.9.4/cc1:
> /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
> /usr/local/lib/libmpfr.1.dylib (compatibility version 3.0.0, current version 3.0.0)
> /usr/local/lib/libgmp.3.dylib (compatibility version 9.0.0, current version 9.2.0)
> /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.7)
> ------------------------
> [Q]: cc1 was linked with libs of another installations (4.4.1) resident in usual /usr/local location? and not with included libs?
>
> And searching for new libs {gmp, mpfr, mpc, isl, cloog, libiconv} i do not find any,
> [Q]:where are (supposed to be) installed after they are build with gcc? i expect to find in /usr/local/gcc-NNN/lib, but apparently gcc-build process use the libs obj without install them?
> ------------------------
> $ ls /usr/local/gcc-4.9.4/lib
> gcc libgcc_s_x86_64.1.dylib libitm.la libstdc++.a
> libatomic.1.dylib libgomp.1.dylib libitm.spec libstdc++.a-gdb.py
> libatomic.a libgomp.a libssp.0.dylib libstdc++.dylib
> libatomic.dylib libgomp.dylib libssp.a libstdc++.la
> libatomic.la libgomp.la libssp.dylib libsupc++.a
> libgcc_ext.10.4.dylib libgomp.spec libssp.la libsupc++.la
> libgcc_ext.10.5.dylib libitm.1.dylib libssp_nonshared.a ppc64
> libgcc_s.1.dylib libitm.a libssp_nonshared.la
> libgcc_s_ppc64.1.dylib libitm.dylib libstdc++.6.dylib
> $ ls /usr/local/gcc-4.9.4/lib/ppc64/
> libatomic.1.dylib libgomp.la libssp.0.dylib libstdc++.a
> libatomic.a libgomp.spec libssp.a libstdc++.a-gdb.py
> libatomic.dylib libitm.1.dylib libssp.dylib libstdc++.dylib
> libatomic.la libitm.a libssp.la libstdc++.la
> libgomp.1.dylib libitm.dylib libssp_nonshared.a libsupc++.a
> libgomp.a libitm.la libssp_nonshared.la libsupc++.la
> libgomp.dylib libitm.spec libstdc++.6.dylib
> ------------------------
> [Q]: Seems that building will use available libs if found, even if are newest in source-tree?
>
> [big(ger)-Q]: Otherwise stated, how to build gcc (not static) with all libs i included, in the single gcc own directory? so the whole can be moved without breaking dependencies, and installed witout overwriting an older installation?
>
>
> Thanks for the attention, and in advance for any idea.
> Greetings
> ----------
> Stefano.B
>
>
>
>
