This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: PATCH PING: Build machinery: Set poststage1_ldflags for all builds


On Tue, Nov 30, 2010 at 7:55 AM, Alexandre Oliva <aoliva@redhat.com> wrote:
> On Nov 29, 2010, Ian Lance Taylor <iant@google.com> wrote:
>
>> - if test "$ENABLE_BUILD_WITH_CXX" = "yes" -a "$poststage1_libs" = ""; then
>> + if test "$poststage1_libs" = ""; then
>> ? ?poststage1_ldflags="-static-libstdc++ -static-libgcc"
>> ? fi
>
> In principle, I think the change fixes an inconsistency, so I don't
> oppose it.
>
> However, given the presented concern:
>
>> the newly built and installed compiler will, in general, only run if
>> the gcc libraries are on the dynamic linker search path
>
> I get a feeling we might be better served by using libtool to link GCC
> executables. ?This would take care of finding libgcc and libstdc++ both
> inside and outside the build tree, and would enable us to take advantage
> of dynamic linking to save disk space and, more importantely, memory for
> compiler users. ?If we feel adventurous, even libbackend could be turned
> into a dynamic library, avoiding the long link times I experience,
> mostly out of copying libbackend, when linking in parallel all
> front-ends with a bunch of concurrent (-O1/-O2/-O3 -m32/-m64) builds.
>
>> People who build distros, or in general people who know that they will
>> install the newly built libraries in a place where the dynamic linker
>> will find them, may use the existing configure option
>> --with-boot-ldflags to control this.
>
> Hmm, I don't think it's that easy. ?We want to use the stage1 libstdc++
> while running the stage2 compiler to build both stage2 libstdc++ (stage1
> in prev-) and stage3 (stage1 in stage1-) front-ends, and we want to use
> the stage2 libstdc++ (in prev-) while running stage3 g++ to build stage3
> libstdc++. ?I don't see how --with-boot-flags can be set so that this
> works, and so that this doesn't encode build-time library search paths
> in binaries that are going to be installed. ?We don't want installed
> compilers to search these temporary directories for libstdc++.

So you say that it's impossible for distributors to avoid the static
link?  What happens when I'd do --with-boot-ldflags without argument?
Are those ldflags appended to the usual ones picking up stage-$prev
libs or do they replace them?

> Now, it's clearly far too late to make this sort of major change at this
> point in the 4.6 cycle, and -static-* is such an easy work-around for
> these complexities, that I'm inclined to accept it.

In general I agree that compiling and installing Go (for example)
should not require to also install libstdc++ or libgcc.  Statically linking
those sounds like a valid approach here.

Thanks,
Richard.

> So, if you get no objections in the next 48 hours or so, please go ahead
> with the patch.
>
> --
> Alexandre Oliva, freedom fighter ? ?http://FSFLA.org/~lxoliva/
> You must be the change you wish to see in the world. -- Gandhi
> Be Free! -- http://FSFLA.org/ ? FSF Latin America board member
> Free Software Evangelist ? ? ?Red Hat Brazil Compiler Engineer
>


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]