[Bug binutils/30082] ld-bootstrap/bootstrap.exp should use LDFLAGS not CFLAGS
https://sourceware.org/bugzilla/show_bug.cgi?id=30082 Romain Geissler changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Romain Geissler --- Hi, My initial issue is fixed (as it was only about not being able to find the zstd lib installed in a non standard location). Despite not passing LDFLAGS to this tests, at least we pass the right library flags, so I would say that is enough for now and we can close this ticket. Cheers, Romain -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30082] ld-bootstrap/bootstrap.exp should use LDFLAGS not CFLAGS
https://sourceware.org/bugzilla/show_bug.cgi?id=30082 --- Comment #1 from Romain Geissler --- Patch posted here: https://sourceware.org/pipermail/binutils/2023-February/125912.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30082] New: ld-bootstrap/bootstrap.exp should use LDFLAGS not CFLAGS
https://sourceware.org/bugzilla/show_bug.cgi?id=30082 Bug ID: 30082 Summary: ld-bootstrap/bootstrap.exp should use LDFLAGS not CFLAGS Product: binutils Version: 2.41 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: romain.geissler at amadeus dot com Target Milestone: --- Hi, I have a new test failure when moving from binutils 2.39 to 2.40, all the bootstap tests fail. Checking the logs, it fails because the lib "-lzstd" can't be found at link time. Checking the code in ld-bootstrap/bootstrap.exp it seems these bootstrap link tests are done using $CFLAGS, while in my case the right "-L/path/to/libzsd" are in $LDFLAGS. Isn't it strange that bootstrap.exp uses CFLAGS while it doesn't compile anything, but tries to link things ? I tried to replace CFLAGS by LDFLAGS, but it seems LDFLAGS isn't passed to DejaGNU's runtest, so it doesn't work either. Instead I have copied my "-L" flag from LDFLAGS to CFLAGS, but it seems more a workaround than an actual fix. Cheers, Romain -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/26406] Extreme assembling time regression with 2.35 and master
https://sourceware.org/bugzilla/show_bug.cgi?id=26406 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #7 from Romain Geissler --- Hi Nick, Now that it has been in master for roughly 10 days, shall this be considered for a backport in the release branch 2.35 ? Cheers, Romain -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26548] LEB decoding error
https://sourceware.org/bugzilla/show_bug.cgi?id=26548 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #4 from Romain Geissler --- Hi Nick, Thanks for this patch. Do you think we should also backport it in the release branch 2.35 ? Cheers, Romain -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25593] --as-needed breaks DT_NEEDED order with linker plugin
https://sourceware.org/bugzilla/show_bug.cgi?id=25593 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #14 from Romain Geissler --- Hi, Do you think this shall be backported to branch 2.34, or can it wait until 2.35 in 6 months ? Cheers, Romain -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #45 from Romain Geissler --- @Nick, are you ok to cherry-pick commits from branch users/hjl/pr25355/binutils-2_34-branch in the official 2.34 branch ? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #43 from Romain Geissler --- Hi, Would it be possible to backport the commits required by this bug in the branch 2.34 that was just released ? That would allow the upcoming gcc 10 (which defaults to -fno-common) to work just fine when combined with -flto and the variety of open source projects using auto tools. Cheers, Romain -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25477] New: ld 2.34 tries to load ${prefix}/etc/ld.so.conf without expanding ${prefix}
https://sourceware.org/bugzilla/show_bug.cgi?id=25477
Bug ID: 25477
Summary: ld 2.34 tries to load ${prefix}/etc/ld.so.conf without
expanding ${prefix}
Product: binutils
Version: 2.34
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: ld
Assignee: unassigned at sourceware dot org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
I noticed a regression between GNU ld 2.33 and GNU ld 2.34 (git branch). I
don't install ld in the default $prefix, and I do have some custom
etc/ld.so.conf in this prefix. With binutils 2.34, it looks like the file
${prefix}/etc/ld.so.conf is ignored and instead it falls back on
/etc/ld.so.conf.
Doing so strace, I saw that actually ld doesn't actually expand the variable
${prefix} and keeps it as is:
[pid 187638] openat(AT_FDCWD, "${prefix}/etc/ld.so.conf", O_RDONLY) = -1 ENOENT
(No such file or directory)
[pid 187638] openat(AT_FDCWD, "/etc/ld.so.conf", O_RDONLY) = 29
It looks like this was caused by commit
d871d478061f10b0879c688e2fa941407e9137aa which did move some code from .em
files (in which I think things like ${XXX} were expanded) to .c files where
expansion do not happen.
Cheers,
Romain
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug ld/24981] Hit assertion failure in ld/ldlang.c:7504
https://sourceware.org/bugzilla/show_bug.cgi?id=24981 --- Comment #7 from Romain Geissler --- I think this should be backported to branch 2.33. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/24981] Hit assertion failure in ld/ldlang.c:7504
https://sourceware.org/bugzilla/show_bug.cgi?id=24981 --- Comment #6 from Romain Geissler --- Thanks, I was just trying to reproduce my issue, in a simpler way than building the full gcc, with no success so far. Cheers, Romain -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/24981] Hit assertion failure in ld/ldlang.c:7504
https://sourceware.org/bugzilla/show_bug.cgi?id=24981 --- Comment #3 from Romain Geissler --- erratum: gcc version: 6.5.0 -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/24981] Hit assertion failure in ld/ldlang.c:7504
https://sourceware.org/bugzilla/show_bug.cgi?id=24981 --- Comment #2 from Romain Geissler --- gcc version used in this CI build: 6.0.5. However I have other builds using the very latest gcc 8 and gcc 9 branches, they fail as well. I haven't checked though if the gcc 8/9 builds are failing the same reason. gmp/mpc/mpfr are all at the latest released version: - gmp: 6.1.2 - mpc: 1.1.0 - mpfr: 4.0.2 Ah and I am using linux x64. -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/24981] New: Hit assertion failure in ld/ldlang.c:7504
https://sourceware.org/bugzilla/show_bug.cgi?id=24981 Bug ID: 24981 Summary: Hit assertion failure in ld/ldlang.c:7504 Product: binutils Version: 2.33 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: romain.geissler at amadeus dot com Target Milestone: --- Hi, I have got a new assertion failure when upgrading in my toolchain binutils from 2.32 branch to the trunk (2.32.51) branch. The error happens when I try to run gcc test suite. I build gmp/mpc/mpfr in the gcc tree directly (not really advocated by gcc developers anymore, but it still works for years), and the issue happens when running the tests of mpfr through the gcc global "make check". For now details are sparse, it happened during a CI build, I don't have access to the artefacts of the build anymore. Logs are showing an assertion error in ld/ldlang.c:7504 libtool: link: /workdir/build/final-system/gcc-build/./prev-gcc/xgcc -B/workdir/build/final-system/gcc-build/./prev-gcc/ -B/opt/1A/toolchain/x86_64-2.6.32-v3.0.79/x86_64-1a-linux-gnu/bin/ -B/opt/1A/toolchain/x86_64-2.6.32-v3.0.79/x86_64-1a-linux-gnu/bin/ -B/opt/1A/toolchain/x86_64-2.6.32-v3.0.79/x86_64-1a-linux-gnu/lib/ -isystem /opt/1A/toolchain/x86_64-2.6.32-v3.0.79/x86_64-1a-linux-gnu/include -isystem /opt/1A/toolchain/x86_64-2.6.32-v3.0.79/x86_64-1a-linux-gnu/sys-include -O2 -msse -msse2 -msse3 -static-libstdc++ -static-libgcc -o tadd_fr tadd_fr.o ./.libs/libmpc-tests.a ../src/.libs/libmpc.a -lmpfr /workdir/build/final-system/gcc-build/./gmp/.libs/libgmp.a -lm libtool: link: /workdir/build/final-system/gcc-build/./prev-gcc/xgcc -B/workdir/build/final-system/gcc-build/./prev-gcc/ -B/opt/1A/toolchain/x86_64-2.6.32-v3.0.79/x86_64-1a-linux-gnu/bin/ -B/opt/1A/toolchain/x86_64-2.6.32-v3.0.79/x86_64-1a-linux-gnu/bin/ -B/opt/1A/toolchain/x86_64-2.6.32-v3.0.79/x86_64-1a-linux-gnu/lib/ -isystem /opt/1A/toolchain/x86_64-2.6.32-v3.0.79/x86_64-1a-linux-gnu/include -isystem /opt/1A/toolchain/x86_64-2.6.32-v3.0.79/x86_64-1a-linux-gnu/sys-include -O2 -msse -msse2 -msse3 -static-libstdc++ -static-libgcc -o t-asmtype t-asmtype.o ../../tests/.libs/libtests.a /workdir/build/final-system/gcc-build/gmp/.libs/libgmp.a ../../.libs/libgmp.a /opt/1A/toolchain/x86_64-2.6.32-v3.0.79/x86_64-1a-linux-gnu/bin/ld: internal error /workdir/src/binutils-2.32.51/ld/ldlang.c 7504 collect2: error: ld returned 1 exit status make[4]: *** [Makefile:2437: tversion] Error 1 make[4]: Leaving directory '/home/jenkins/workspace/OTF_Toolchain_release_3.0/output/build/final-system/gcc-build/mpfr/tests' make[3]: *** [Makefile:4186: check-am] Error 2 make[3]: Leaving directory '/home/jenkins/workspace/OTF_Toolchain_release_3.0/output/build/final-system/gcc-build/mpfr/tests' make[2]: *** [Makefile:498: check-recursive] Error 1 make[2]: Leaving directory '/home/jenkins/workspace/OTF_Toolchain_release_3.0/output/build/final-system/gcc-build/mpfr' make[1]: *** [Makefile:6255: check-mpfr] Error 2 make[1]: *** Waiting for unfinished jobs Note that I build gcc (and thus mpfr) using LTO, as it is configured to do a PGO + LTO bootstrap build. The asserting code is the one added by this commit: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=128bf1fe608badb59d27f9c5c8ffb1a6a6d9d811 If you need more details, I can try to reproduce this issue locally, but might take some time as a gcc LTO + PGO build is quite long. Cheers, Romain -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/24853] OSABI not set when STT_GNU_IFUNC or STB_GNU_UNIQUE symbols output
https://sourceware.org/bugzilla/show_bug.cgi?id=24853 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/24342] New: [gold] Avoid plt generation for function pointer when building with -fno-plt
https://sourceware.org/bugzilla/show_bug.cgi?id=24342 Bug ID: 24342 Summary: [gold] Avoid plt generation for function pointer when building with -fno-plt Product: binutils Version: 2.32 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: romain.geissler at amadeus dot com CC: ian at airs dot com Target Milestone: --- Hi, I have a case locally where ld.bfd and ld.gold don't perform the same kind of relocation wrt PLT generation when initially building with -fno-plt. Please see this remark in this gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88954#c7 which I copy/paste here: <https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/24123] incremental_copy_test failure when building with gcc-9
https://sourceware.org/bugzilla/show_bug.cgi?id=24123 --- Comment #1 from Romain Geissler --- Hi, Is it a dup of PR23539 ? Cheers, Romain -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/23539] --incremental-update doesn't work with GNU properties
https://sourceware.org/bugzilla/show_bug.cgi?id=23539 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/24123] incremental_copy_test failure when building with gcc-9
https://sourceware.org/bugzilla/show_bug.cgi?id=24123 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23818] Symbols from discarded section in IR object leaked into final executable
https://sourceware.org/bugzilla/show_bug.cgi?id=23818 --- Comment #5 from Romain Geissler --- After rebuilding libssh2 and a few other open source libraries, now indeed I don't see any more these odd absolute relocations, and now ld.lld happily accepts them as valid input .so files. So it looks like you fixed it ;) Is it ok to backport in release branch 2.31 ? Cheers, Romain -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23818] Symbols from discarded section in IR object leaked into final executable
https://sourceware.org/bugzilla/show_bug.cgi?id=23818 --- Comment #3 from Romain Geissler --- Thanks, I will check that this indeed fixes my case with libssh2. I understand this problem is not really wide and might actually affect just me since I don't expect that using -ffat-lto-objects is very common, but do you think this commit deserves to be backported on branch 2.31, or do you prefer I patch it manually on my side until 2.32 is out ? Cheers, Romain -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gas/23645] New: Backport as .st_ino/.st_dev check to check input and output are different
https://sourceware.org/bugzilla/show_bug.cgi?id=23645 Bug ID: 23645 Summary: Backport as .st_ino/.st_dev check to check input and output are different Product: binutils Version: 2.31 Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: romain.geissler at amadeus dot com Target Milestone: --- Hi, Recently the commit: commit 2a50366ded329bfb39d387253450c9d5302c3503 Author: Robert Yang Date: Tue Aug 14 12:22:35 2018 +0100 which was applied to master fixed the problem described in https://sourceware.org/ml/binutils/2018-08/msg00193.html It was reviewed, modified, approved and applied by Nick Clifton here: https://sourceware.org/ml/binutils/2018-08/msg00273.html Since it affects the release 2.31 (I had the issue when using the release branch), can you please backport it to branch 2.31 as well ? Thanks, Romain -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/23499] Incorrect code in bfd_elf_record_link_assignment
https://sourceware.org/bugzilla/show_bug.cgi?id=23499 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #6 from Romain Geissler --- Hi, Can you please apply this patch too on the 2.31 release branch ? We just hit this issue by using the latest commit from this branch. That will avoid other people hitting the same issue in the future. Thanks, Romain -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/23620] New: [gold] Support jobserver with --threads
https://sourceware.org/bugzilla/show_bug.cgi?id=23620 Bug ID: 23620 Summary: [gold] Support jobserver with --threads Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: gold Assignee: ccoutant at gmail dot com Reporter: romain.geissler at amadeus dot com CC: ian at airs dot com Target Milestone: --- Hi, The current gold implementation tries to create by default as many threads as the number of inputs, which can lead on big projects to EAGAIN error when calling pthread_create. An alternative is to define --thread-count, however this also scale poorly when you build in parallel several big binaries and each of them eat N threads. Would it be possible to implement a jobserver inside gold, similar to what can be found in gcc with -flto=jobserver. GNU Make describes how a jobserver aware tool shall behave: https://www.gnu.org/software/make/manual/html_node/POSIX-Jobserver.html Cheers, Romain -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug ld/22758] FAIL: Run pr22393-2
https://sourceware.org/bugzilla/show_bug.cgi?id=22758 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #7 from Romain Geissler --- Hi, Long story short, I was trying to build clang in PGO+LTO bootstrap mode the last few days, and the bootstrap fails with a segfault at the moment clang is ran on the profiling data set. I hunted down the issue to the fact that in some LLVM libraries, "atexit" function is inlined and included in the loaded shared libraries, but placed in a section that ld.so mapped in a RW segment rather than a RE segment, and both segment are not correctly aligned to the boundary of a 2MB page like it should. When applying this patch, the bootstrap of clang works. Given that this might potentially happen arbitrarily to any user of binutils 2.30 and it is not so easy to understand that section placement is wrong here, would you please backport this to the 2.30 branch ? Thanks, Romain -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/21841] FAIL: debug_msg.sh with GCC 7
https://sourceware.org/bugzilla/show_bug.cgi?id=21841 --- Comment #2 from Romain Geissler --- Created attachment 10491 --> https://sourceware.org/bugzilla/attachment.cgi?id=10491=edit Possible workaround in the gold testsuite (not a nice one...) -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug gold/21841] FAIL: debug_msg.sh with GCC 7
https://sourceware.org/bugzilla/show_bug.cgi?id=21841 Romain Geissler changed: What|Removed |Added CC||romain.geissler at amadeus dot com --- Comment #1 from Romain Geissler --- Hi, I think this is more a gcc bug. The gold test is about checking that "OverriddenCFunction" is not reported as an error. This one is defined in odr_violation2.cc from line 23 to 25. However, here in the error reported by the linker, it's about SometimesInlineFunction which is really defined from line 27 to 29 in odr_violation2.cc but is reported to be at line 25 in the linker error. This is most likely because gcc provided the linker with wrong line information. Cheers, Romain -- You are receiving this mail because: You are on the CC list for the bug. ___ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
[Bug binutils/20177] New: ld ignores --with-lib-path and -L for indirectly loaded libraries
https://sourceware.org/bugzilla/show_bug.cgi?id=20177
Bug ID: 20177
Summary: ld ignores --with-lib-path and -L for indirectly
loaded libraries
Product: binutils
Version: 2.26
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: romain.geissler at amadeus dot com
Target Milestone: ---
Hi,
I am wondering what is the expected behavior of ld when a library is implicitly
loaded. What should be the behavior of the linker when:
- libA.so depends on libB.so (there is a DT_NEEDED entry for libB.so in
libA.so)
- I link main.o against libA.so, but because my Makefile is wrongly written I
forget to link it against libB.so as well
?
Currently it looks like ld tries to open and link against libB.so even if it
doesn't explicitly appear on the command line. But it appears that ld is
completely ignoring the configure-time option --with-lib-path, as well as all
the -L/path/to/lib that gcc passes to the linker, and looks for libraries in
/lib64 instead. As a result, if I link against a library that requires pthread
without the "-pthread" or "-lpthread" flag, then ld ends up trying to link
against /lib64/libpthread.so.0 rather than
/opt/1A/toolchain/x86_64-2.6.32-v3-0/lib/libpthread.so.0 that I would expect
since I used at configure time
--with-lib-path=/opt/1A/toolchain/x86_64-2.6.32-v3-0/lib. I have a custom GNU
toolchain (gcc, binutils, glibc) correctly bootstrapped with the correct
--prefix installed in /opt/1A/toolchain/x86_64-2.6.32-v3-0. This toolchain is
using a glibc that is more recent than the system one (installed in /li64).
Since there is a glibc mismatch, when using the system's libpthread.so rather
than the custom one, I end up with link errors.
Here is how I reproduce it:
# Makefile #
export PATH:=/opt/1A/toolchain/x86_64-2.6.32-v3/bin:${PATH}
LDFLAGS+=-Wl,-v
all:test
libA.so:CFLAGS=-fPIC
libA.so:LDFLAGS:=${LDFLAGS} -shared -pthread
libA.so:libA.c
$(LINK.c) $< $(LOADLIBES) $(LDLIBS) -o $@
test:LDFLAGS:=${LDFLAGS} -L. -lA
# Uncomment the following to have a proper configuration
#test:LDFLAGS:=${LDFLAGS} -pthread
test:test.c libA.so
$(LINK.c) $< $(LOADLIBES) $(LDLIBS) -o $@
clean:
${RM} libA.so test
.PHONY:all clean
# libA.c #
#include
int f()
{
return errno;
}
# test.c #
int main() {}
Notice the error of configuration in the makefile where "test" is not built
with -pthread while in theory it should.
When I build this, I end up with:
cc -fPIC -Wl,-v -shared -pthread libA.c -o libA.so
collect2 version 6.1.1 20160511
/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1/../../../../x86_64-1a-linux-gnu/bin/ld
-plugin
/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../libexec/gcc/x86_64-1a-linux-gnu/6.1.1/liblto_plugin.so
-plugin-opt=/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../libexec/gcc/x86_64-1a-linux-gnu/6.1.1/lto-wrapper
-plugin-opt=-fresolution=/gctmp/rgeissler/ccVWxeIP.res
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lpthread -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --build-id
--eh-frame-hdr --hash-style=gnu -m elf_x86_64 -shared -z relro
--enable-new-dtags -o libA.so
/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1/../../../../lib64/crti.o
/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1/crtbeginS.o
-L/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1
-L/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc
-L/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1/../../../../lib64
-L/opt/1A/toolchain/x86_64-2.6.32-v3-0/lib/../lib64
-L/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1/../../../../x86_64-1a-linux-gnu/lib
-L/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1/../../..
-L/opt/1A/toolchain/x86_64-2.6.32-v3-0/lib -v /gctmp/rgeissler/ccdS9FX6.o -lgcc
--as-needed -lgcc_s --no-as-needed -lpthread -lc -lgcc --as-needed -lgcc_s
--no-as-needed
/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1/crtendS.o
/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1/../../../../lib64/crtn.o
GNU ld (GNU Binutils) 2.26.0.20160511
cc -Wl,-v -L. -lA test.c -o test
collect2 version 6.1.1 20160511
/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../lib/gcc/x86_64-1a-linux-gnu/6.1.1/../../../../x86_64-1a-linux-gnu/bin/ld
-plugin
/softntools/opt/1A/toolchain/x86_64-2.6.32-v3-0/bin/../libexec/gcc/x86_64-1a-linux-gnu/6.1.1/liblto_plugin.so
-plugin-opt
