Re: Build gcc-4.9.4 on OSX-ppc with included requirements, but linked otherwise.

[ssbb <effed3s at gmail dot com>]

Hello

 thanks Iain, you explain clearly, here and in the other response on 
thread, what i supposed...

On 03/12/2017 10:10 PM, Iain Sandoe wrote:
> 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)

This was not mandatory, only originated from reading about problems in 
symbol resolution with too old libiconv in osx-10.5.8, and having this 
kind of problems time ago, i applied the solution before the problem, 
and  actually ld proved against, the gcc was compiled and tested without 
issues (apparently).


> 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.

Before, i try to build requirements separately, and next give the 
--with- switches  but gcc build complain about 'different architecture', 
i don't investigated much, but leaving the whole process at gcc 
eliminated this issue.


> 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).

Yes, agree, seems a better/safer pratice, and give more control options 
over build process.


> Of course, that’s up to you to decide on the basis of your requirements.
>
> Anyway, hopefully, that helps explain what you see,
>
> Iain

Thanks again
------------
Stefano.B