-static-libgcc vs. -Wl,-Bstatic -lgcc

[Magnus Ihse Bursie]

Also, I think I'm mixing up -static-gcc and -static-stdc++. 

/Magnus

> 13 jun 2015 kl. 09:01 skrev Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>:
> 
> Volker,
> 
> Thanks for your analysis. The static/dynamic stdc++ linking is messy, quite possibly even broken in the current implemenation. I have opened a bug for that but can't find it now. The current implemenation in libraries.m4 will replace LDCXX (that is, g++) with LD (that is, gcc) which caused some internal Oracle code to break. Apparently, it works without breaking the build for the open part, but that still looks weird. If we explicitly request to use a toolchain which links with g++, then we shouldn't replace it with gcc just because we're doing static linking. 
> 
> Also, I had not heard about -static-libgcc before (and apparently hadn't Fredrik who wrote the original piece of --with-stdc++lib handling), but it seems like that should be used, for all the platform, yes. 
> 
> Do we even have to use  -Wl,-Bstatic -lstdc++ when -static-libgcc is present?
> 
> If it turns out that this is something we will want to fix in jdk9/dev as well, we typically do either of:
> A) fixing it directly in jdk9/dev as a separate bug, and then pull it into build-infra after a while when it's propagated into a build, or
> B) fix it in build-infra, and then pick the relevant parts and put them as a separate bug into jdk9/dev, possibly requiring some merge changes when they get back after a while. 
> 
> B is preferable if it's required urgently in build-infra, or it might need several iterations to get it right. Otherwise A is simpler. 
> 
> /Magnus
> 
>> 12 jun 2015 kl. 19:50 skrev Volker Simonis <volker.simonis at gmail.com>:
>> 
>> Hi,
>> 
>> while porting the new HS build to linux/ppc64 I saw that we are now setting
>> some link options unconditionally trough the $(LIBCXX) variable from the
>> top-level spec.gmk (whihc is good :). With the default configuration, this
>> variable will contain the value "-Wl,-Bstatic -lstdc++ -lgcc" but this can
>> be changed by setting --with-stdc++lib=dynamic. Nevertheless, we still set
>> "-static-libgcc" unconditionally in Common.gmk
>> 
>> Now there's one think I don't understand (and which isn't related to
>> ppc64). I thought "-static-libgcc" and "-Wl,-Bstatic -lgcc" should be
>> equivalent options, but apparently they aren’t. For the new build we use
>> "-Wl,-Bstatic -lstdc++ -lgcc" and additionally set "-static-libgcc". I
>> thought it should be possible to remove the "-static-libgcc" setting from
>> the new HS build system (because the question static/dynamic linking of
>> libstdc++ should be decided at configure time with the --with-stdc++lib
>> option. But this will produce a different results.
>> 
>> Summing it up:
>> 
>> old build:
>> -static-libgcc -Wl,-Bstatic -lstdc++       -Wl,-Bdynamic -lm -ldl -lpthread
>> 
>> is the same as new build:
>> -static-libgcc -Wl,-Bstatic -lstdc++ -lgcc -Wl,-Bdynamic -lm -ldl -lpthread
>> 
>> but not the same as the new build without "-static-libgcc":
>>              -Wl,-Bstatic -lstdc++ -lgcc -Wl,-Bdynamic -lm -ldl -lpthread
>> which dynamically links ibgcc_s.so.1 (at least on x86_64)
>> 
>> It turns out (if you run gcc with '-v') that with "-static-libgcc" the
>> command line expands to:
>> -lgcc -lgcc_eh -lc -lgcc -lgcc_eh
>> which will all be statically linked.
>> 
>> while without "-static-libgcc" it expands to:
>> -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
>> --no-as-needed
>> and dynamically links libgcc_s.so.1 (at least on x86_64 but not on ppc64).
>> 
>> The problem is that "libgcc_s.so.1" is only available as shared library so
>> we can't statically link it even if we want.
>> 
>> So should we move "-static-libgcc" to libraries.m4 to the place where we
>> detect whether to use  --with-stdc++lib=static/dynamic because we
>> apparently can't live without it if we still want to link libgcc statically?
>> 
>> Regards,
>> Volker