[Bug libctf/28933] buffer overflow on powerpc-linux
https://sourceware.org/bugzilla/show_bug.cgi?id=28933 Nick Alcock changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at sourceware dot org |nick.alcock at oracle dot com --- Comment #1 from Nick Alcock --- Interesting! I routinely do both, so this must be a recent regression (well, ok, as recent as a few months ago. I'll get back to libctf soon.) This is assembler input for a corrupted CTF dict, but we shouldn't buffer-overrun even in that case. The fundamental problem is that ctf_bufopen trusts the length it was passed in the ctf_sect_t (it has to: that's the only length it gets), but never checks that the CTF header is consistent with it. (Fixing that will break the test: I'll fix it so it still tests what it's meant to, and add a new test for this case.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/28933] buffer overflow on powerpc-linux
https://sourceware.org/bugzilla/show_bug.cgi?id=28933 --- Comment #2 from Nick Alcock --- FWIW, I cannot replicate this: not with the x86->ppc cross shown here, nor on ppc native, nor on ppc64. Nonetheless we should armour against this. I'll see what I can do... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/28933] buffer overflow on powerpc-linux
https://sourceware.org/bugzilla/show_bug.cgi?id=28933 --- Comment #4 from Nick Alcock --- Aha! Yep, that's got it. Thank you, your object file was very helpful. Now to fix it... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/28933] buffer overflow on powerpc-linux
https://sourceware.org/bugzilla/show_bug.cgi?id=28933 --- Comment #5 from Nick Alcock --- This unchecked length is only an overrun in the uncompressed-and-corrupted foreign-endian CTF case (it's still wrong if the CTF is uncompressed but native-endian, but it's only used at serialization time, which is something you can't do to a dict you read out of a CTF section, since those are read-only). So, fairly obscure. Still not sure why it didn't happen to me: I can make it happen with a new testcase easily now. (Fixed, I think: will test my fix properly tomorrow.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/28933] buffer overflow on powerpc-linux
https://sourceware.org/bugzilla/show_bug.cgi?id=28933 Nick Alcock changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Nick Alcock --- Done, and backported. Can backport further if anyone wants. My test matrix now includes a test run under valgrind with LIBCTF_WRITE_FOREIGN_ENDIAN=t set in the environment, and I have verified that setting this on a little-endian machine produces CTF identical to that written on a big-endian machine without that flag set. So we should now be testing the overflowing path routinely, and this should not recur. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/29242] New: ld crash when deduplicating CTF from multiple .o files with the same name
https://sourceware.org/bugzilla/show_bug.cgi?id=29242 Bug ID: 29242 Summary: ld crash when deduplicating CTF from multiple .o files with the same name Product: binutils Version: 2.38 Status: NEW Severity: normal Priority: P2 Component: libctf Assignee: unassigned at sourceware dot org Reporter: nick.alcock at oracle dot com Target Milestone: --- We observe on Gentoo a crash when linking Mesa 22.0.3 when compiled with -gctf. GDB reports: Starting program: /usr/bin/ld --eh-frame-hdr -m elf_x86_64 -shared -o src/gallium/targets/dri/libgallium_dri.so /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/crtbeginS.o -L/usr/lib/llvm/13/lib64 -L/usr/lib/llvm/13/lib64 -L/usr/lib/llvm/13/lib64 -L/usr/lib/llvm/13/lib64 -L/usr/lib/llvm/13/lib64 -L/usr/lib/llvm/13/lib64 -L/usr/lib/llvm/13/lib64 -L/usr/lib/llvm/13/lib64 -L/usr/lib/llvm/13/lib64 -L/usr/lib/llvm/13/lib64 -L/usr/lib/llvm/13/lib64 -L/usr/lib/llvm/13/lib64 -L/usr/lib/llvm/13/lib64 -L/usr/lib/llvm/13/lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1 -L/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.1/../../.. src/gallium/targets/dri/libgallium_dri.so.p/target.c.o src/gallium/targets/dri/libgallium_dri.so.p/megadriver_stub.c.o --as-needed --no-undefined --start-group -soname libgallium_dri.so -O1 --as-needed --defsym=__gentoo_check_ldflags__=0 -rpath /../../../mapi/shared-glapi -rpath-link /var/tmp/portage/media-libs/mesa-22.0.3/work/mesa-22.0.3-abi_x86_64.amd64/src/mapi/shared-glapi src/gallium/frontends/dri/libdri.a src/util/libmesa_util.a src/util/format/libmesa_format.a src/mesa/libmesa.a src/compiler/glsl/libglsl.a src/compiler/glsl/glcpp/libglcpp.a src/compiler/nir/libnir.a src/compiler/libcompiler.a src/mesa/libmesa_sse41.a src/gallium/auxiliary/libgalliumvl.a src/gallium/auxiliary/libgallium.a src/mapi/shared-glapi/libglapi.so.0.0.0 src/gallium/auxiliary/pipe-loader/libpipe_loader_static.a src/loader/libloader.a src/util/libxmlconfig.a src/gallium/winsys/sw/null/libws_null.a src/gallium/winsys/sw/wrapper/libwsw.a src/gallium/winsys/sw/dri/libswdri.a src/gallium/winsys/sw/kms-dri/libswkmsdri.a src/gallium/drivers/llvmpipe/libllvmpipe.a src/gallium/drivers/softpipe/libsoftpipe.a src/gallium/drivers/r300/libr300.a src/gallium/winsys/radeon/drm/libradeonwinsys.a src/gallium/drivers/r600/libr600.a src/gallium/drivers/radeonsi/libradeonsi_gfx6.a src/gallium/drivers/radeonsi/libradeonsi_gfx7.a src/gallium/drivers/radeonsi/libradeonsi_gfx8.a src/gallium/drivers/radeonsi/libradeonsi_gfx9.a src/gallium/drivers/radeonsi/libradeonsi_gfx10.a src/gallium/drivers/radeonsi/libradeonsi_gfx103.a src/gallium/drivers/radeonsi/libradeonsi.a src/gallium/winsys/amdgpu/drm/libamdgpuwinsys.a src/amd/addrlib/libaddrlib.a src/amd/common/libamd_common.a src/amd/llvm/libamd_common_llvm.a src/gallium/winsys/nouveau/drm/libnouveauwinsys.a src/gallium/drivers/nouveau/libnouveau.a src/gallium/drivers/i915/libi915.a src/gallium/winsys/i915/drm/libi915drm.a src/gallium/drivers/iris/libiris.a src/gallium/drivers/iris/libiris_per_hw_ver80.a src/gallium/drivers/iris/libiris_per_hw_ver90.a src/gallium/drivers/iris/libiris_per_hw_ver110.a src/gallium/drivers/iris/libiris_per_hw_ver120.a src/gallium/drivers/iris/libiris_per_hw_ver125.a src/intel/compiler/libintel_compiler.a src/intel/dev/libintel_dev.a src/intel/isl/libisl.a src/intel/isl/libisl_per_hw_ver40.a src/intel/isl/libisl_per_hw_ver50.a src/intel/isl/libisl_per_hw_ver60.a src/intel/isl/libisl_per_hw_ver70.a src/intel/isl/libisl_per_hw_ver75.a src/intel/isl/libisl_per_hw_ver80.a src/intel/isl/libisl_per_hw_ver90.a src/intel/isl/libisl_per_hw_ver110.a src/intel/isl/libisl_per_hw_ver120.a src/intel/isl/libisl_per_hw_ver125.a src/intel/isl/libisl_tiled_memcpy.a src/intel/isl/libisl_tiled_memcpy_sse41.a src/intel/blorp/libblorp.a src/intel/perf/libintel_perf.a src/intel/common/libintel_common.a src/intel/ds/libintel-driver-ds.a src/gallium/winsys/iris/drm/libiriswinsys.a src/gallium/drivers/crocus/libcrocus.a src/gallium/drivers/crocus/libcrocus_per_hw_ver40.a src/gallium/drivers/crocus/libcrocus_per_hw_ver45.a src/gallium/drivers/crocus/libcrocus_per_hw_ver50.a src/gallium/drivers/crocus/libcrocus_per_hw_ver60.a src/gallium/drivers/crocus/libcrocus_per_hw_ver70.a src/gallium/drivers/crocus/libcrocus_per_hw_ver75.a src/gallium/drivers/crocus/libcrocus_per_hw_ver80.a src/gallium/winsys/crocus/drm/libcrocuswinsys.a --build-id=sha1 --gc-sections --version-script /var/tmp/portage/media-libs/mesa-22.0.3/work/mesa-22.0.3/src/gallium/targets/dri/dri.sym --dynamic-list /var/tmp/portage/media-libs/mesa-22.0.3/work/mesa-22.0.3/src/gallium/targets/dri/../dri-vdpau.dyn /usr/lib64/libdrm.so -lLLVM-13 /usr/lib64
[Bug libctf/29242] ld crash when deduplicating CTF from multiple .o files with the same name
https://sourceware.org/bugzilla/show_bug.cgi?id=29242 Nick Alcock changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nick.alcock at oracle dot com Status|NEW |ASSIGNED --- Comment #1 from Nick Alcock --- (Fix being locally tested.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/29242] ld crash when deduplicating CTF from multiple .o files with the same name
https://sourceware.org/bugzilla/show_bug.cgi?id=29242 --- Comment #3 from Nick Alcock --- Fix will be in 2.39. (Backport to 2.38 under test.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/29242] ld crash when deduplicating CTF from multiple .o files with the same name
https://sourceware.org/bugzilla/show_bug.cgi?id=29242 Nick Alcock changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Nick Alcock --- Fixed in 2.38 and 2.39. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/29547] binutils-2.39: fails to build against cctools nm (no '-B' option support)
https://sourceware.org/bugzilla/show_bug.cgi?id=29547 Nick Alcock changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2022-09-05 --- Comment #1 from Nick Alcock --- Adding an exit status test seems like a good idea, yes. I'll do that in the next few days (busy, but this is easy and machine time is cheap). I don't have access to a Darwin machine and the compile farm obviously doesn't have any -- could you check that the result works once I have something? (The reason for the oddness of this test is simply that we have to run nm on *something*, and many implementations forbid running it on /dev/null, and *correct* output on every implementation I have seen includes the file name. Of course, multi-line error messages might too... oops. I hope an exit status test will suffice to avoid that.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/29547] binutils-2.39: fails to build against cctools nm (no '-B' option support)
https://sourceware.org/bugzilla/show_bug.cgi?id=29547 --- Comment #3 from Nick Alcock --- Having nm be a shell wrapper should be fine (I've been testing some of the odder edge cases that way). That's one reason we look through $PATH to find it ;) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/29547] binutils-2.39: fails to build against cctools nm (no '-B' option support)
https://sourceware.org/bugzilla/show_bug.cgi?id=29547 --- Comment #4 from Nick Alcock --- Oh this gets more fun. We can't use the exit code because some nm's return a nonzero exit code if no symbols are found! I'll have to add a grosser hack, looking for the string 'invalid argument' (in the C locale, naturally). This makes me feel rather ill :/ (It's starting to feel easier to compile something and then try to look for its symbols, but at this stage I don't think we are guaranteed a working compiler.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/29547] binutils-2.39: fails to build against cctools nm (no '-B' option support)
https://sourceware.org/bugzilla/show_bug.cgi?id=29547 Nick Alcock changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #5 from Nick Alcock --- Something else! What if nm emits actual successful output? No nm out there is going to include its own name in the output in that case. We have to look for the expected format of the output (at least slightly) and consider the option accepted if that matches. Anyway, I have something that might just work: try the users/nalcock/libtool-nm branch on binutils-gdb git. (It doesn't break x86 Linux, Solaris 2.11 or FreeBSD 13, which is all I've tested so far.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/29547] binutils-2.39: fails to build against cctools nm (no '-B' option support)
https://sourceware.org/bugzilla/show_bug.cgi?id=29547 Nick Alcock changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nick.alcock at oracle dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27360] libctf.so.0: undefined symbol: bsearch_r
https://sourceware.org/bugzilla/show_bug.cgi?id=27360 Nick Alcock changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #26 from Nick Alcock --- This looks to be resolved now. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27305] relinking libctf during install does not find libbfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27305 --- Comment #8 from Nick Alcock --- ... any movement on this? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/29547] binutils-2.39: fails to build against cctools nm (no '-B' option support)
https://sourceware.org/bugzilla/show_bug.cgi?id=29547 --- Comment #7 from Nick Alcock --- (Sorry for delay: post-conf collapse, UK bank holiday, massive change of monitor configuration meaning my displays were scattered all around the room for a day, etc) On 14 Sep 2022, slyich at gmail dot com outgrape: > checking for BSD- or MS-compatible name lister (nm)... = > error: > /nix/store/kpc4vpii3zrnz53b87xvid0rxlqb66cc-cctools-binutils-darwin-949.0.1/bin/nm: > invalid argument -B > Usage: > /nix/store/kpc4vpii3zrnz53b87xvid0rxlqb66cc-cctools-binutils-darwin-949.0.1/bin/nm > [-agnopruUmxjlfAP[s segname sectname] [-] [-t format] [[-arch ] > ...] > [file ...] > = Oh, multiple lines ending with a usage message, and with the last line citing the name of the running binary? OK, we can trigger on 'Usage: ' then. (Ew. Still, most unlikely to be a word that appears on the last line of a legitimate run. This function *really* needs a proper rewrite...) Try the branch now? (Tested locally as before, plus on mingw.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/29547] binutils-2.39: fails to build against cctools nm (no '-B' option support)
https://sourceware.org/bugzilla/show_bug.cgi?id=29547 --- Comment #9 from Nick Alcock --- On 20 Sep 2022, slyich at gmail dot com spake thusly: > Seems to build binutils just fine! Detected `nm -p` command option. Great! It'll go in the next tranche, and probably be backported to 2.39. (But that's a week or so off -- long test runs plus a bunch of other stuff I want to get in at the same time, courtesy of feature requests at LPC. :) ) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/29547] binutils-2.39: fails to build against cctools nm (no '-B' option support)
https://sourceware.org/bugzilla/show_bug.cgi?id=29547 Nick Alcock changed: What|Removed |Added Status|WAITING |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/29983] New: 2.36+ type confusion in outdated-input warning causes out-of-bounds access and possible overwrite
https://sourceware.org/bugzilla/show_bug.cgi?id=29983 Bug ID: 29983 Summary: 2.36+ type confusion in outdated-input warning causes out-of-bounds access and possible overwrite Product: binutils Version: 2.36 Status: NEW Severity: normal Priority: P2 Component: libctf Assignee: unassigned at sourceware dot org Reporter: nick.alcock at oracle dot com Target Milestone: --- The observed failure looks like this when running the testsuite: failed with: , expected: FAIL: Diagnostics - No parent dictionary Originally reported by Matthias Klose: Indu Bhagat provided a nice traceback and much invaluable debugging without which tracking this down would have been a nightmare. Thank you both! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/29983] 2.36+ type confusion in outdated-input warning causes out-of-bounds access and possible overwrite
https://sourceware.org/bugzilla/show_bug.cgi?id=29983 Nick Alcock changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nick.alcock at oracle dot com Status|NEW |ASSIGNED --- Comment #1 from Nick Alcock --- Fix under test. The root cause of this is a bug in the code which checks for outdated object file inputs from old compilers that emitted a func info section format that has never been supported by libctf: it mistakenly uses the wrong type for the value of the ctf_link_inputs hashtable and treats it as a much larger structure than it is: if unlucky and the controlling test fails, it tries to add stuff to a list of errors and warnings located far beyond the *actual* end of the structure in ctf_link_inputs. It rarely bites in practice because it is relatively unlikely to happen on systems with 64-bit pointers: we dereference the second pointer element of (what we think is a) ctf_dict and then dig out its fourth byte (the header flags word), but the corresponding element in the real structure is part of the ctfa_magic in a ctf_archive (always allocated in a normal ld link), and it just so happens that on a platform with 64-bit pointers the relevant bit of the magic appears to have the relevant flags turned off. But on 32-bit this can really bite, though it is very unlikely to cause anything but a crash and would require near-total control of the process and careful preparation of the heap to cause it to produce anything more than a crash. Nonetheless, will backport the fix to all applicable branches. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/30013] [2.40 regression] Assertion failed: one_type != two_type, file libctf/ctf-dedup.c, line 2342, function sort_output_mapping
https://sourceware.org/bugzilla/show_bug.cgi?id=30013 Nick Alcock changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at sourceware dot org |nick.alcock at oracle dot com --- Comment #1 from Nick Alcock --- Looks like it. This is strange because the no-qsort case is *meant* to get routinely tested... as is Solaris 11.3. But I don't often do full GCC bootstraps on it, so I guess we can see how this got past. I bet the underlying problem is that I missed the case where sort_output_mapping is called with the same arg twice (in which case it should obviously return 0). Some qsort implementations will do that, some won't, and I don't see anything preventing ctf-qsort.c from doing that :/ Taken, will fix and backport to 2.40. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/30013] [2.40 regression] Assertion failed: one_type != two_type, file libctf/ctf-dedup.c, line 2342, function sort_output_mapping
https://sourceware.org/bugzilla/show_bug.cgi?id=30013 --- Comment #2 from Nick Alcock --- Replicated. I also observe a bunch of failures in the libctf and ld/ld-ctf testsuites, all of the form you report. Fix under test (at first sight it appears to fix it), and I've audited all qsort uses in libctf for further instances of the same problem (none found), and added a qsort_r-disabling test run to my ever-growing routine test set, so this should not recur. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/30013] [2.40 regression] Assertion failed: one_type != two_type, file libctf/ctf-dedup.c, line 2342, function sort_output_mapping
https://sourceware.org/bugzilla/show_bug.cgi?id=30013 --- Comment #3 from Nick Alcock --- It's curious that this works in 2.39: going by the source code it should have been broken all the way from the introduction of the deduplicator in 2.36, since we always sorted the output mappings so that objdump --ctf output was stable enough for the testsuite comparison process. I'm not going to look that particular gift horse in the mouth too hard though :) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/30226] New: CTF deduplication is incompatible with -femit-struct-debug-detailed=base
https://sourceware.org/bugzilla/show_bug.cgi?id=30226
Bug ID: 30226
Summary: CTF deduplication is incompatible with
-femit-struct-debug-detailed=base
Product: binutils
Version: 2.36
Status: NEW
Severity: normal
Priority: P2
Component: libctf
Assignee: unassigned at sourceware dot org
Reporter: nick.alcock at oracle dot com
Target Milestone: ---
Minimal reproducer:
[ibhagat@ibhagatpc final2]$ cat t.i
# 8 ""
typedef struct
{
union
{
int addr4;
int addr6[4];
} u_ipaddr;
} KS_IPADDR;
KS_IPADDR KsSockOp_KsSockOp_op;
[ibhagat@ibhagatpc final2]$ rm -rf t.o; gcc -gctf -g -g -O2
-femit-struct-debug-detailed=base -o t.o -c t.i; ld -r -o temp_t.o t.o;
CTF error: /home/ibhagat/data1/gcc-temp/stacktrace/ctf/dbgrid/final2/ (0):
while emitting deduplicated forward, error emitting target type from input type
1
CTF error: deduplicating link type emission failed for
/home/ibhagat/data1/gcc-temp/stacktrace/ctf/dbgrid/final2/
ld: warning: CTF linking failed; output will have no CTF section: Type name
must not be empty.
This is because this option causes the emission of a typedef pointing to a
forward with no name, which is a bizarre artifact that is impossible to write
in plain C and which libctf prohibits the creation of:
0x1: (kind 9) struct
0x2: (kind 10) KS_IPADDR -> 0x1: (kind 9) struct
The deduplicator does its job and tries to emit this thing into the output, and
fails because it makes no sense. This is a good thing because had it worked the
result would have been wrong: all those empty structs would have been
considered identical and merged together, but in fact they should only be
considered identical to other struct KS_IPADDRs.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug libctf/30226] CTF deduplication is incompatible with -femit-struct-debug-detailed=base
https://sourceware.org/bugzilla/show_bug.cgi?id=30226 Nick Alcock changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at sourceware dot org |nick.alcock at oracle dot com --- Comment #1 from Nick Alcock --- Testing a fix now. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/30264] New: offsets of fields in unnamed structures/unions are wrong
https://sourceware.org/bugzilla/show_bug.cgi?id=30264
Bug ID: 30264
Summary: offsets of fields in unnamed structures/unions are
wrong
Product: binutils
Version: 2.36
Status: NEW
Severity: normal
Priority: P2
Component: libctf
Assignee: unassigned at sourceware dot org
Reporter: nick.alcock at oracle dot com
Target Milestone: ---
In e.g.
struct A
{
int a;
char *b;
struct
{
struct
{
char *one;
int two;
};
};
};
offsetof (struct A, one) is most unlikely to be zero; but
ctf_member_info (CTF_type_corresponding_to_A, "one") returns zero every time.
This is obviously wrong: ctf_member_info() recurses to anonymous struct
children but does not add the offset of the anonymous struct to the offset it
returns.
(A secondary but much less significant problem is that ctf_add_member() of
fields to such structures should return ECTF_DUPLICATE if the name exists in
any of the containing structures or in any underlying anonymous ones. Of course
this is only likely to happen if the compiler is buggy or something very
strange is being hand-built using the ctf_add*() functions.)
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug libctf/30264] offsets of fields in unnamed structures/unions are wrong
https://sourceware.org/bugzilla/show_bug.cgi?id=30264 Nick Alcock changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nick.alcock at oracle dot com Status|NEW |ASSIGNED --- Comment #1 from Nick Alcock --- Testing a fix. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/30264] offsets of fields in unnamed structures/unions are wrong
https://sourceware.org/bugzilla/show_bug.cgi?id=30264 Nick Alcock changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Nick Alcock --- Fixed on master and 2.40. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/30013] [2.40 regression] Assertion failed: one_type != two_type, file libctf/ctf-dedup.c, line 2342, function sort_output_mapping
https://sourceware.org/bugzilla/show_bug.cgi?id=30013 Nick Alcock changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Nick Alcock --- Fixed on master and 2.40 (finally: sorry about that). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/29983] 2.36+ type confusion in outdated-input warning causes out-of-bounds access and possible overwrite
https://sourceware.org/bugzilla/show_bug.cgi?id=29983 Nick Alcock changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Nick Alcock --- I was vaguely hoping to backport it further, but being realistic that seems unlikely to happen given that I haven't done it since January. Closed as resolved. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27967] Build failure on solaris-11 ld: fatal: option --version-script requires option -z gnu-version-script-compat to be specified
https://sourceware.org/bugzilla/show_bug.cgi?id=27967 Nick Alcock changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #9 from Nick Alcock --- This is now in a released binutils, so I think we can probably close it. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/30226] CTF deduplication is incompatible with -femit-struct-debug-detailed=base
https://sourceware.org/bugzilla/show_bug.cgi?id=30226 Nick Alcock changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #2 from Nick Alcock --- The fix failed to work badly enough that it's clear the right place to fix this is in GCC: a fix is being worked on there instead. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/30985] New: ctf_add_member_encoded of a type on a parent dumps core
https://sourceware.org/bugzilla/show_bug.cgi?id=30985
Bug ID: 30985
Summary: ctf_add_member_encoded of a type on a parent dumps
core
Product: binutils
Version: 2.41
Status: NEW
Severity: normal
Priority: P2
Component: libctf
Assignee: unassigned at sourceware dot org
Reporter: nick.alcock at oracle dot com
Target Milestone: ---
This dumps core:
ctf_dict_t *fp;
ctf_encoding_t e = { CTF_INT_SIGNED, 0, sizeof (long) };
ctf_id_t type;
int err;
if ((fp = ctf_create (&err)) == NULL)
/* error handling */
if ((type = ctf_add_struct (fp, CTF_ADD_ROOT, "foo")) == CTF_ERR)
/* error handling */
if (ctf_add_member_encoded (fp, type, "member", 666, 5, e) == CTF_ERR)
/* error handling */
Now this is obviously invalid code (emitting a member of a nonexistent garbage
type ID). But this also dumps core for the same reason:
ctf_dict_t *pfp, *cfp;
ctf_encoding_t e = { CTF_INT_SIGNED, 0, sizeof (long) };
ctf_id_t ptype;
int err;
if ((pfp = ctf_create (&err)) == NULL)
/* error handling */
if ((cfp = ctf_create (&err)) == NULL)
/* error handling */
if (ctf_import (cfp, pfp) < 0)
/* error handling */
if ((ptype = ctf_add_integer (pfp, CTF_ADD_NONROOT, "int", &e)) == CTF_ERR)
/* error handling */
if ((stype = ctf_add_struct (cfp, CTF_ADD_ROOT, "foo")) == CTF_ERR)
/* error handling */
if (ctf_add_member_encoded (cfp, stype, "cmember", ptype, 5, e) == CTF_ERR)
/* error handling */
The underlying problem is that ctf_add_member_encoded operation looks up the
DTD of 'ptype' to try to figure out its type kind (for error handling), but
does not allow for the possibility that the DTD lookup might fail. Firstly, of
course, it might fail because you provided an invalid ptype; but secondly, DTD
lookup doesn't recurse to parents if nothing is found in a child dict, but
ctf_add_member_encoded() assumes that it does.
An audit while fixing this revealed other, related problems with ctf_set_array,
ctf_add_enumerator, ctf_add_member and ctf_add_member_offset, all of which
produce ECTF_BADID errors if asked to modify a type in an imported parent dict
via a child dict.
Fixing. Thanks to Kris Van Hees for identifying the first of these problems and
tracking it down.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug libctf/30985] ctf_add_member_encoded of a type on a parent dumps core
https://sourceware.org/bugzilla/show_bug.cgi?id=30985 Nick Alcock changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at sourceware dot org |nick.alcock at oracle dot com --- Comment #1 from Nick Alcock --- There are no uses of any of these functions in crash-inducing or error-inducing ways in the linker or CTF deduplicator; the deduplicator never calls ctf_add_member_encoded at all, and when it adds types to the parent dict it always does so directly, never via the child. So this only affects other client uses (but it can indeed affect those, and has). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/31882] libctf: fails test suite on 32-bit platforms due to incorrect format specifiers
https://sourceware.org/bugzilla/show_bug.cgi?id=31882 --- Comment #4 from Nick Alcock --- This patch replaces a non-%z with a %z -- can we actually rely on %z working these days? I used to have to use %i and casts... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/31882] libctf: fails test suite on 32-bit platforms due to incorrect format specifiers
https://sourceware.org/bugzilla/show_bug.cgi?id=31882 --- Comment #7 from Nick Alcock --- Thanks, Alan. I can start using %z without fear from now on, as opposed to just accidentally using it out of habit and then cursing and reverting it when it breaks on mingw. (I'm fairly sure that when libctf was first merged, %z didn't work on at least one platform. Nowadays the GCC shipped with mingw complains about it, but this is a bug in that version of GCC -- fixed in later releases -- and the actual mingw libc handles it fine.) Thanks for the fix! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 Nick Alcock changed: What|Removed |Added CC|nix at esperi dot org.uk |nick.alcock at oracle 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 binutils/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 Nick Alcock changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nick.alcock at oracle 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 binutils/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 Nick Alcock changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-10-21 Ever confirmed|0 |1 -- 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/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 --- Comment #2 from Nick Alcock --- (For the avoidance of doubt: the commenter above was me, logged in under the wrong bugzilla account.) -- 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/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 --- Comment #4 from Nick Alcock --- The C compiler shouldn't affect anything here: the linker in use is what matters. I'll try to get tcc working in a bit, but in the absence of that you could try to figure out which symbol in ctf-open-bfd.c is at fault (or if it's all of them). Surely the thing doesn't just pull in the whole .a file blindly: you'd hardly be able to link anything when using tcc if that were true (and many binaries would be enormous: .a files are used as intermediate stages in building larger projects a *lot*). -- 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/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 --- Comment #8 from Nick Alcock --- Nice diagnosis! Looks like there are some bugs in busybox and tcc to fix. I agree that the first three things you reported are bugs, and I'll fix them once I get a spare moment. Thanks for the report! -- 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/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 --- Comment #12 from Nick Alcock --- Thanks! I already have that locally -- I really should finish testing and submit everything. Simply removing __thread won't do, unfortunately: it makes libctf even less threadsafe than it already is, and I'm trying to get it *more* threadsafe. The only thing that's held me off fixing this bug (other than pressure of other work, like the deduplicating CTF linker) is the annoyance of having to implement bsearch_r :) but I suppose I can take the bsearch from glibc without worries. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/25216] libctf doesn't respect a build configured with --with-system-zlib
https://sourceware.org/bugzilla/show_bug.cgi?id=25216 Nick Alcock changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at sourceware dot org |nick.alcock at oracle dot com --- Comment #1 from Nick Alcock --- Hm, curious. I build with --with-system-zlib all the time, you'd think I'd have noticed this. Will look into it. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 Nick Alcock changed: What|Removed |Added Component|binutils|libctf -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/25216] libctf doesn't respect a build configured with --with-system-zlib
https://sourceware.org/bugzilla/show_bug.cgi?id=25216 Nick Alcock changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #2 from Nick Alcock --- This appears to work to me: % ../configure --enable-shared --with-system-zlib && make -j 30 [... successful build ...] % grep '^zlib' libctf/config.log zlibdir='' zlibinc='' % ldd libctf/.libs/libctf.so.0 linux-vdso.so.1 (0x7ffe607f1000) libz.so.1 => /lib/libz.so.1 (0x7fcefb674000) libbfd-2.33.50.20191213.so => not found libc.so.6 => /lib/libc.so.6 (0x7fcefb2bb000) /lib64/ld-linux-x86-64.so.2 (0x7fcefbaa6000) Could you provide more details? I'm sure I'm just missing some obscure edge case where it is incorrectly building the source tree's zlib... or I fixed it by accident while fixing some other related bugs in the libctf configury. (I'll be pushing what I'm testing here fairly soon.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/25155] libctf directory doesn't compile with MinGW
https://sourceware.org/bugzilla/show_bug.cgi?id=25155 Nick Alcock changed: What|Removed |Added CC||nick.alcock at oracle dot com Component|binutils|libctf --- Comment #2 from Nick Alcock --- Thank you! (And sorry for not noticing this bug flying by.) I'm looking at this now (see recent traffic on the mailing list). All the patches Joel has proposed look good, but I think I have a way to fix the E* class of problems for all time, at the cost of a slight API break affecting no existing users (see the RFC patch I just posted). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 --- Comment #14 from Nick Alcock --- CTF is not ELF-specific. The only intrinsically ELF-specific portion of libctf is the machinery which associates symbol table entries with CTF entries, and that isn't even fully implemented yet (because I haven't got to it). Some things are only implemented for ELF but are perfectly implementable for other executable formats, notably ctf_open() and ctf_fdopen(), and the sharing of strings with the executable's string table. A fix for this is going through review and should probably be applied soon. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 --- Comment #16 from Nick Alcock --- Clearly I should get back to this. Sorry for the near-complete absence: I've been digging away at obstinate bugs in the CTF deduplicator... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 --- Comment #18 from Nick Alcock --- I am not dead (and am in fact working on nothing but libctf). Sorry, I fell behind while doing piles of linker dedup work: it was a pain, with at least two designs that fell apart at the last minute, but it's more or less working now, and I'll be getting the terrifying pile of patches that resulted (and this lot, too) into shape after I've knocked the last niggles out of it. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/25120] Portability issues in binutils 2.33 due to libctf
https://sourceware.org/bugzilla/show_bug.cgi?id=25120 --- Comment #19 from Nick Alcock --- Sent rebased-and-tested series for review. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/26934] [2.36 Regression] ctf-dump.c:406:4: error: format not a string literal and no format arguments [-Werror=format-security]
https://sourceware.org/bugzilla/show_bug.cgi?id=26934 Nick Alcock changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nick.alcock at oracle dot com --- Comment #2 from Nick Alcock --- Thanks for the report (and the fix), integrating now. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/26934] [2.36 Regression] ctf-dump.c:406:4: error: format not a string literal and no format arguments [-Werror=format-security]
https://sourceware.org/bugzilla/show_bug.cgi?id=26934 Nick Alcock changed: What|Removed |Added Status|NEW |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27117] In libctf, make AC_CONFIG_MACRO_DIR consistent with ACLOCAL_AMFLAGS
https://sourceware.org/bugzilla/show_bug.cgi?id=27117 Nick Alcock changed: What|Removed |Added CC||nick.alcock at oracle dot com --- Comment #5 from Nick Alcock --- I don't see this either, but it does no harm and is pretty clearly the right thing to do. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27250] Installation of 2.36 fails with 'LIBCTF_1.1 not found' followed by 'relink' suggestion
https://sourceware.org/bugzilla/show_bug.cgi?id=27250 Nick Alcock changed: What|Removed |Added CC||nick.alcock at oracle dot com --- Comment #1 from Nick Alcock --- This is exceptionally strange. (And needless to say is not ever supposed to happen!) Subsequent links are failiong because ld itself uses libctf: that part is understandable... the hard part is how the libctf you just linked can possibly not have the LIBCTF_1.1 version in it. It should be there! The output of readelf -V libctf/.libs/libctf.so (before the install) might be helpful in figuring out what on earth is going on. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27250] Installation of 2.36 fails with 'LIBCTF_1.1 not found' followed by 'relink' suggestion
https://sourceware.org/bugzilla/show_bug.cgi?id=27250 --- Comment #3 from Nick Alcock --- Ohhh I bet I know what it is. You'll need to roll back by sticking the old ld in place (I hope you have a copy) or roll forward by hand-copying .libs/libctf.so.0 into place in /usr/local. The problem is installation order: ld is being installed before libctf, but ld *uses* libctf and thus if libctf is relinked for any reason by the install phase, ld might find itself calling on symbols that aren't in the libctf already present on the system (if it even is there). Should have a fix for you to test in a few minutes. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27250] Installation of 2.36 fails with 'LIBCTF_1.1 not found' followed by 'relink' suggestion
https://sourceware.org/bugzilla/show_bug.cgi?id=27250 Nick Alcock changed: What|Removed |Added Last reconfirmed||2021-01-26 Ever confirmed|0 |1 Assignee|unassigned at sourceware dot org |nick.alcock at oracle dot com Status|UNCONFIRMED |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27250] Installation of 2.36 fails with 'LIBCTF_1.1 not found' followed by 'relink' suggestion
https://sourceware.org/bugzilla/show_bug.cgi?id=27250 --- Comment #4 from Nick Alcock --- Created attachment 13159 --> https://sourceware.org/bugzilla/attachment.cgi?id=13159&action=edit Fix ld-versus-libctf installation ordering -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27250] Installation of 2.36 fails with 'LIBCTF_1.1 not found' followed by 'relink' suggestion
https://sourceware.org/bugzilla/show_bug.cgi?id=27250 --- Comment #7 from Nick Alcock --- OK, I'll work on upstreaming it. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27250] Installation of 2.36 fails with 'LIBCTF_1.1 not found' followed by 'relink' suggestion
https://sourceware.org/bugzilla/show_bug.cgi?id=27250 Nick Alcock changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Nick Alcock --- On master and 2.36. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27297] libctf.a malformed, build fails on x86_64-apple-darwin18.7.0
https://sourceware.org/bugzilla/show_bug.cgi?id=27297 Nick Alcock changed: What|Removed |Added Status|NEW |ASSIGNED CC||nick.alcock at oracle dot com Assignee|unassigned at sourceware dot org |nick.alcock at oracle dot com --- Comment #3 from Nick Alcock --- Replicated. Working on a fix. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27482] parallel make -j 16 install falls over in 2.36
https://sourceware.org/bugzilla/show_bug.cgi?id=27482 Nick Alcock changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at sourceware dot org |nick.alcock at oracle dot com CC||nick.alcock at oracle dot com Last reconfirmed||2021-03-02 Ever confirmed|0 |1 --- Comment #1 from Nick Alcock --- Ugh. I do this all the time and it's never failed. I hate parallelism bugs :) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27482] parallel make -j 16 install falls over in 2.36
https://sourceware.org/bugzilla/show_bug.cgi?id=27482 Nick Alcock changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #2 from Nick Alcock --- Could you try the users/nalcock/ld-ctf-install-deps branch I just created? (It's based on 2.36.x.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27482] parallel make -j 16 install falls over in 2.36
https://sourceware.org/bugzilla/show_bug.cgi?id=27482 --- Comment #4 from Nick Alcock --- ./configure --disable-gdb ... should do what you want. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27297] libctf.a malformed, build fails on x86_64-apple-darwin18.7.0
https://sourceware.org/bugzilla/show_bug.cgi?id=27297
Nick Alcock changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED|RESOLVED
--- Comment #5 from Nick Alcock ---
Fixed (some time back, but couldn't update the bug) in master in a series in
which the most important commits are these:
(not sure if it is worthy of going back into 2.36. The commits it relies on are
quite big and invasive.)
commit 95148614026da7353721411dd020d024667e3482
Author: Nick Alcock
Date: Wed Feb 3 18:42:06 2021 +
bfd, opcodes, libctf: support --with-included-gettext
Right now, these libraries hardwire -L../intl -lintl on a few fixed
platforms, which works fine on those platforms but on other platforms
leads to shared libraries that lack libintl_* symbols when configured
--with-included-gettext, and/or static libraries that contain libintl as
*another* static library. If we instead use the LIBINTL variable
defined in ../intl/config.intl, this gives us the right thing on all
three classes of platform (gettext in libc, gettext in system libintl,
gettext in ../intl/libintl.a).. This also means we can rip out some
Darwin-specific machinery from configure.ac and also simplify the Cygwin
side.
This also means that the libctf testsuite (and other places that include
libbfd, libopcodes or libctf) don't need to grow libintl dependencies
just on account of those libraries (though they still need such
dependencies if they themselves use gettext machinery).
bfd/ChangeLog
2021-02-03 Nick Alcock
* configure.ac (SHARED_LIBADD): Remove explicit -lintl population
in
favour of LIBINTL.
* configure: Regenerated.
libctf/ChangeLog
2021-02-02 Nick Alcock
* configure.ac (CTF_LIBADD): Remove explicit -lintl population in
favour of LIBINTL.
* Makefile.am (libctf_nobfd_la_LIBADD): No longer explicitly
include $(LIBINTL).
(check-DEJAGNU): Pass down to tests as well.
* configure: Regenerated.
* Makefile.in: Likewise.
opcodes/ChangeLog
2021-02-04 Nick Alcock
* configure.ac (SHARED_LIBADD): Remove explicit -lintl population
in
favour of LIBINTL.
* configure: Regenerated.
commit aee224d6434c08a1404a4357cf0a664a4c2f02eb
Author: Nick Alcock
Date: Thu Feb 4 16:58:35 2021 +
intl: turn LIBINTL into -L / -l form
This variable currently refers directly, not to a .la file, but to an .a
file. This produces wrong results when building into a library on some
platforms: so convert it to the general form "-L${top_builddir}../intl
-lintl ..." ... so that both libtool and non-libtool builds will always
do the right thing for both static and shared links.
intl/ChangeLog
2021-02-04 Nick Alcock
* configure.ac (LIBINTL): Transform into -L/-lintl form.
* configure: Regenerate.
commit 53d4244ec0ac70438d75abf3326cb3392bb9c828
Author: Nick Alcock
Date: Tue Feb 2 15:39:26 2021 +
intl: always picify
libintl is included in several shared libraries (at least
libinproctrace.so and libctf.so): unconditionally picify with code
borrowed from libiberty configure. (It's not performance-critical, so
don't bother making separate PIC and non-PIC libraries like libiberty
does.)
intl/ChangeLog
2021-02-02 Nick Alcock
* aclocal.m4: include picflag.m4.
* configure.ac (PICFLAG): Add and substitute.
* Makefile.in (PICFLAG): New.
(COMPILE): Use it.
* configure: Regenerate.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug libctf/27360] libctf.so.0: undefined symbol: bsearch_r
https://sourceware.org/bugzilla/show_bug.cgi?id=27360 Nick Alcock changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 CC||nick.alcock at oracle dot com Last reconfirmed||2021-03-09 --- Comment #5 from Nick Alcock --- This suggests that libctf.so has not had needed symbols from libiberty built into it properly (and bsearch_r is not called on by anything else in ld, so ld will fail). This is quite strange given that we are still linking -liberty in even after that commit. At any rate, I do not see this with binutils master, so it's quite likely that the fixes for bug 27297 fixed this too (even if I have no immediate idea why it happened in the first place). Could you try it and see? (If so, I guess I'll have to backport this pile of commits to stable, even though I was hoping to avoid doing so because it affects a lot of things other than just ld.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27297] libctf.a malformed, build fails on x86_64-apple-darwin18.7.0
https://sourceware.org/bugzilla/show_bug.cgi?id=27297 --- Comment #7 from Nick Alcock --- Quite possibly, or at least I don't see that failure with the reported replication mechanism on binutils master: I'll update that bug too. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27360] libctf.so.0: undefined symbol: bsearch_r
https://sourceware.org/bugzilla/show_bug.cgi?id=27360 Nick Alcock changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nick.alcock at oracle dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27360] libctf.so.0: undefined symbol: bsearch_r
https://sourceware.org/bugzilla/show_bug.cgi?id=27360 --- Comment #7 from Nick Alcock --- This is probably related to the version of binutils installed *before* you do a make install. What version are you installing on top of? This may be a dup of #27482: could you see if the users/nalcock/ld-ctf-install-deps branch fixes it? (You may need to configure with --disable-gdb to get around an unrelated gdb build breakage in the tree I happened to build this branch on top of.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27482] parallel make -j 16 install falls over in 2.36
https://sourceware.org/bugzilla/show_bug.cgi?id=27482 Nick Alcock changed: What|Removed |Added Status|WAITING |ASSIGNED --- Comment #7 from Nick Alcock --- Ugh, agreed. I failed to notice that install-strip and install are treated separately. Another patch coming later today. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27482] parallel make -j 16 install falls over in 2.36
https://sourceware.org/bugzilla/show_bug.cgi?id=27482 Nick Alcock changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #8 from Nick Alcock --- OK, so, with the caveat that I can't make this go wrong at all, try the code now on users/nalcock/ld-ctf-install-deps, which covers the strip targets too. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27482] parallel make -j 16 install falls over in 2.36
https://sourceware.org/bugzilla/show_bug.cgi?id=27482 Nick Alcock changed: What|Removed |Added Status|WAITING |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27482] parallel make -j 16 install falls over in 2.36
https://sourceware.org/bugzilla/show_bug.cgi?id=27482 Nick Alcock changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Nick Alcock --- Fix now on 2.36 and master. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27360] libctf.so.0: undefined symbol: bsearch_r
https://sourceware.org/bugzilla/show_bug.cgi?id=27360 --- Comment #9 from Nick Alcock --- OK, I'm fairly sure this is fixed on master now -- could you give it a try? (It might well be fixed on the 2.36 branch as well.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27628] UBSAN error: binutils-gdb/libctf/ctf-serialize.c:852:4:
https://sourceware.org/bugzilla/show_bug.cgi?id=27628 Nick Alcock changed: What|Removed |Added Last reconfirmed||2021-03-23 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Component|binutils|libctf Assignee|unassigned at sourceware dot org |nick.alcock at oracle dot com --- Comment #1 from Nick Alcock --- Thanks for the report! Confirmed with a native x86-pc-linux-gnu compiler (i.e. no crossing needed for this). Looks like my test matrix just grew again :) (I also need to turn on ASAN_OPTIONS=detect_odr_violation=0 to prevent glibc-induced failures on every single test, including the "is CTF supported in the compiler?" test, but C doesn't have an ODR so we don't need to worry about those failures anyway. :) .) It revealed a tiny memory leak too. I'll fix both. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27628] UBSAN error: binutils-gdb/libctf/ctf-serialize.c:852:4:
https://sourceware.org/bugzilla/show_bug.cgi?id=27628 --- Comment #2 from Nick Alcock --- Diagnosed. This is fallout from my recent dtd revamping, so does not affect 2.36. It relates specifically to functions with no arguments, but of course those are quite common... there is also a much older failure in isqualifier(), though it only triggers if the compiler does not optimize away the dereference in &foo[out_of_range_value]. We also have some failures diagnosed in the ld testsuite, though you have to turn off leak detection there or the thing again wrongly concludes that CTF isn't supported because the -gt test throws out a leak detection. Squashing a bunch of related bugs now: will push something for you to test later today. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27628] UBSAN error: binutils-gdb/libctf/ctf-serialize.c:852:4:
https://sourceware.org/bugzilla/show_bug.cgi?id=27628 Nick Alcock changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #3 from Nick Alcock --- Pushed something for you to try to users/nalcock/ctf-sanitized: give it a try? (It fixes a bunch of other related problems: LDFLAGS=-ldl and/or LIBS=-ldl should no longer be necessary.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27628] UBSAN error: binutils-gdb/libctf/ctf-serialize.c:852:4:
https://sourceware.org/bugzilla/show_bug.cgi?id=27628 Nick Alcock changed: What|Removed |Added Status|WAITING |ASSIGNED -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27628] UBSAN error: binutils-gdb/libctf/ctf-serialize.c:852:4:
https://sourceware.org/bugzilla/show_bug.cgi?id=27628 Nick Alcock changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Nick Alcock --- All fixed, I think (and I'm now running the sanitizers in my own test runs). (Fix is on master only.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27360] libctf.so.0: undefined symbol: bsearch_r
https://sourceware.org/bugzilla/show_bug.cgi?id=27360 --- Comment #11 from Nick Alcock --- I can confirm that libctf is being relinked during install (though ld does not). However, for me, this does not fail: we have always installed libbfd first and the link works. I think I need a full log of stdout/stderr over make install on a failing system: there must be something wrong but at this stage I'm not sure what it is. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27360] libctf.so.0: undefined symbol: bsearch_r
https://sourceware.org/bugzilla/show_bug.cgi?id=27360 --- Comment #12 from Nick Alcock --- In particular, the relink line I see is: cd /home/oranix/oracle/private/binutils-gdb/foo/libctf; /bin/sh /home/oranix/oracle/private/binutils-gdb/foo/libctf/libtool --tag CC --mode=relink gcc -std=gnu99 -Wall -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -pedantic -Wno-long-long -I../../libctf/../zlib -march=x86-64 -mtune=generic -O2 -pipe -fno-plt -version-info 0:0:0 -Wl,--version-script=../../libctf/libctf.ver -Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now -o libctf.la -rpath /usr/local/lib libctf_la-ctf-archive.lo libctf_la-ctf-dump.lo libctf_la-ctf-create.lo libctf_la-ctf-decl.lo libctf_la-ctf-error.lo libctf_la-ctf-hash.lo libctf_la-ctf-labels.lo libctf_la-ctf-dedup.lo libctf_la-ctf-link.lo libctf_la-ctf-lookup.lo libctf_la-ctf-open.lo libctf_la-ctf-serialize.lo libctf_la-ctf-sha1.lo libctf_la-ctf-string.lo libctf_la-ctf-subr.lo libctf_la-ctf-types.lo libctf_la-ctf-util.lo libctf_la-ctf-open-bfd.lo ../bfd/libbfd.la -L/home/oranix/oracle/private/binutils-gdb/foo/libctf/../libiberty/pic -liberty -L./../zlib -lz -ldl Note that -L is used to point to the in-tree PIC libiberty (which is always an .a file) right before -liberty is pulled in, so we don't end up trying to look at /usr/local/lib/libiberty.a or something (which might not contain the symbols we need). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27360] libctf.so.0: undefined symbol: bsearch_r
https://sourceware.org/bugzilla/show_bug.cgi?id=27360 --- Comment #15 from Nick Alcock --- The real question is where the -L/usr/lib is coming from. If you dig into config.status it should become clear. I bet this is derived from some .la file somewhere, so that libtool thinks it needs -L/usr/lib -lfoo to get at libfoo, and this causes trouble for everything else later in the link line. Including syslibdirs in libtool .la files like that is generally considered to be a problem with the local system's setup (though because libtool has no real way to work around it or stop it from happening, it is depressingly common). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27360] libctf.so.0: undefined symbol: bsearch_r
https://sourceware.org/bugzilla/show_bug.cgi?id=27360 --- Comment #18 from Nick Alcock --- Yeah, that's only true if the distributor chooses to install the iibiberty.a from GCC in /usr/lib (or, I suppose, the one from a sufficiently recnet binutils). I do still want to figure out how to fix this properly. Sorry it's taking me so long to get to it... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27297] libctf.a malformed, build fails on x86_64-apple-darwin18.7.0
https://sourceware.org/bugzilla/show_bug.cgi?id=27297 --- Comment #8 from Nick Alcock --- Now I know the cause of that bug: no, these are unrelated (and a separate fix is needed for that bug). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27360] libctf.so.0: undefined symbol: bsearch_r
https://sourceware.org/bugzilla/show_bug.cgi?id=27360 --- Comment #20 from Nick Alcock --- ... never mind, doing that regresses elsewhere. Still looking at it, I'm sure this is soluble ) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27360] libctf.so.0: undefined symbol: bsearch_r
https://sourceware.org/bugzilla/show_bug.cgi?id=27360 --- Comment #21 from Nick Alcock --- OK, try the users/nalcock/libctf-install-relink branch now. Still testing here, but things are looking better (make check passing and install-time relinking always linking against the libiberty in the build tree). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27360] libctf.so.0: undefined symbol: bsearch_r
https://sourceware.org/bugzilla/show_bug.cgi?id=27360 --- Comment #19 from Nick Alcock --- After a lot of struggling, I can now trigger an install-time relink and see it triggering searches of very much the wrong place for libiberty.a (the install tree, even if --enable-install-libiberty was not passed in, which means it could be linking against *anything*). This is clearly wrong. The CTF_LIBADD stuff in libctf/configure.ac is supposed to force searches for libiberty induced by libctf to go to the right place, but it's not working because the -L for that is in the wrong place in the link line. A likely fix was trivial once I knew what was going on. If anyone can still reproduce this (and I can do so even on a system using GCC 11 by brutally ar d'ing bsearch_r.o from the installed libiberty.a, then doing another make install of binutils), could you try the users/nalcock/libctf-install-relink branch I just pushed? It seems to work for me in quick tests (though full, crazily longwinded tests will obviously be needed given that this is a build system change and they are always fraught). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27305] relinking libctf during install does not find libbfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27305
--- Comment #4 from Nick Alcock ---
That's extremely odd. What is the contents of /opt/emlix/test/sysroot/usr/lib?
In particular, is libbfd.{so,a} of any description visible in there after the
failed installation? Because it should be: bfd is always 'make install' before
libctf, and you didn't specify --disable-install-libbfd.
(Maybe this is sysroot-related?)
Reinvoking the link command libtool says it's executing (in the libctf
directory of the build tree) and adding -Wl,--verbose will give you a pile of
output which will in part say where ld is looking for libraries. That might be
informative, perhaps.
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug libctf/27305] relinking libctf during install does not find libbfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27305 --- Comment #6 from Nick Alcock --- (... if Source Mage always removes packages before installing them, how does it install make or coreutils? I suppose I should download it and have a look!) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27305] relinking libctf during install does not find libbfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27305 --- Comment #5 from Nick Alcock --- The Source Mage bug is probably a different problem again, and I think it's more a Source Mage problem really. It is in general not safe to remove toolchain binaries completely before 'make install' for precisely the reason shown here: a working toolchain may well be needed at installation time, since libtool can decide that it needs to invoke the compiler and linker during installation (this routinely happens for GCC, too). (This is distinct from the other problem in this bug, which is mostly about installing binutils without having .a/.so files from an existing binutils around, not about installing binutils without having a working ld at all.) To me this feels like something the Source Mage package installer should deal with in another way. The simplest but ugliest approaches might be to *move* the old ld somewhere else and drop a temporary symlink into the GCC tooldir so that gcc still works at installation time, or by simply not removing the old linker at all. But the *right* approach is probably to do a 'make install' into a temporary DESTDIR, and only *then* remove the old toolchain and move the DESTDIRed stuff into place. This last option is what more or less every other package manager-driven build system does these days, and is essentially required for a wide variety of packages for safe installation, from glibc to Rust. So I suspect your build system can already do it, and just isn't doing it for binutils :) if it can't do it, it should learn, because installing glibc via a straight 'make install' is *dangerous* and is likely to lead to an out-of-sync ld.so and libc and a system on which every dynamically-linked binary fails to start. (I don't see an obvious way to lift the requirement for a working linker at make install time without breaking invocation of built binaries from the build tree and thus breaking the testsuite, or reimplementing half of libtool badly inside the libctf testsuite, which seems even worse. This requirement is not new: it's as old as Libtool, and binutils-gdb triggered it for other packages even before now, notably GDB. Maybe you didn't notice this because you split GDB into a separate package, so the linker wasn't removed when that was installed.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/25155] libctf directory doesn't compile with MinGW
https://sourceware.org/bugzilla/show_bug.cgi?id=25155 Nick Alcock changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Nick Alcock --- This seems to have been fixed (by Eli: thank you!) for some time now. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27305] relinking libctf during install does not find libbfd
https://sourceware.org/bugzilla/show_bug.cgi?id=27305 Nick Alcock changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-06-15 Status|UNCONFIRMED |WAITING CC||nick.alcock at oracle dot com --- Comment #2 from Nick Alcock --- This is probably a duplicate of bug 27360. Could you try the users/nalcock/libctf-install-relink branch and see if that fixes it? (libtool has to relink libctf during installation because during installation it is linked with explicit RPATHs which point into the build tree, so that you can run programs that link to it directly without installing its dependencies, as the libctf testsuite does. OF course, that RPATH has to be stripped out at install time without pulling in a libbfd from /usr/local/lib or wherever... which turns out to be quite tricky.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27967] Build failure on solaris-11 ld: fatal: option --version-script requires option -z gnu-version-script-compat to be specified
https://sourceware.org/bugzilla/show_bug.cgi?id=27967 Nick Alcock changed: What|Removed |Added Last reconfirmed||2021-06-22 CC||nick.alcock at oracle dot com Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 --- Comment #3 from Nick Alcock --- Hm. --gnu-version-script and -z gnu-version-script appear to be recent enough that no machines in the compile farm support it, which makes it hard to replicate this. Nonetheless, I agree that doing a full link test should handle this case better. We could also check for --gnu-version-script, but without knowing how much of the GNU syntax is supported and with no way to test it myself this feels a little risky. Myself, I hit bigger trouble trying to build on Solaris 11: /bin/sh ./libtool --tag=CC --mode=link gcc -std=gnu99 -Wall -W -Wall -Wno-narrowing -Wwrite-strings -Wmissing-format-attribute -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -pedantic -Wno-long-long -I../../libctf/../zlib -g -O2 -version-info 0:0:0 -export-symbols-regex ctf_.* -o libctf.la -rpath /usr/local/lib libctf_la-ctf-archive.lo libctf_la-ctf-dump.lo libctf_la-ctf-create.lo libctf_la-ctf-decl.lo libctf_la-ctf-error.lo libctf_la-ctf-hash.lo libctf_la-ctf-labels.lo libctf_la-ctf-dedup.lo libctf_la-ctf-link.lo libctf_la-ctf-lookup.lo libctf_la-ctf-open.lo libctf_la-ctf-serialize.lo libctf_la-ctf-sha1.lo libctf_la-ctf-string.lo libctf_la-ctf-subr.lo libctf_la-ctf-types.lo libctf_la-ctf-util.lo libctf_la-ctf-qsort_r.lo libctf_la-ctf-open-bfd.lo ../bfd/libbfd.la -L/export/home/nix/binutils-gdb/foo/libctf/../libiberty/pic -liberty -lintl -L./../zlib -lz libtool: link: nm .libs/libctf_la-ctf-archive.o .libs/libctf_la-ctf-dump.o .libs/libctf_la-ctf-create.o .libs/libctf_la-ctf-decl.o .libs/libctf_la-ctf-error.o .libs/libctf_la-ctf-hash.o .libs/libctf_la-ctf-labels.o .libs/libctf_la-ctf-dedup.o .libs/libctf_la-ctf-link.o .libs/libctf_la-ctf-lookup.o .libs/libctf_la-ctf-open.o .libs/libctf_la-ctf-serialize.o .libs/libctf_la-ctf-sha1.o .libs/libctf_la-ctf-string.o .libs/libctf_la-ctf-subr.o .libs/libctf_la-ctf-types.o .libs/libctf_la-ctf-util.o .libs/libctf_la-ctf-qsort_r.o .libs/libctf_la-ctf-open-bfd.o | | /opt/csw/bin/gsed 's/.* //' | sort | uniq > .libs/libctf.exp A pair of pipes with nothing between them is going to work really well! This is because symbol_pipe is unset in libtool, shown by checking for sparc-sun-solaris2.11-ranlib... (cached) ranlib checking command to parse nm output from gcc object... failed This is because nm of /dev/null on Solaris 11.3 at least is emitting complaints about /dev/null not being a regular file rather than trying to *do* anything, so NM never gets set to nm -p and parsing fails: even if it succeeded, the list of symbol-type codes in libtool.m4 is out of date for Solaris 11, which breaks the test too. This means that builds on a stock Solaris 11 box seem likely to fail in any case. Both these bugs can be fixed by suitably editing the top-level libtool.m4: I'll submit this to GCC (as needed for toplevel stuff) as well as binutils. (I'd submit it to libtool itself, but that seems to be dead.) With that hacked around... I still can't reproduce your problem because I don't yet have access to a recent-enough Solaris box (though this will change in a couple of days): but I'll work on doing a proper link-time test anyway, since it's clear that what's there is inadequate. More shortly. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27967] Build failure on solaris-11 ld: fatal: option --version-script requires option -z gnu-version-script-compat to be specified
https://sourceware.org/bugzilla/show_bug.cgi?id=27967 Nick Alcock changed: What|Removed |Added Assignee|unassigned at sourceware dot org |nick.alcock at oracle dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27967] Build failure on solaris-11 ld: fatal: option --version-script requires option -z gnu-version-script-compat to be specified
https://sourceware.org/bugzilla/show_bug.cgi?id=27967 Nick Alcock changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #4 from Nick Alcock --- FYI, I think I have full support for symbol versioning on Solaris 11.4 working now. Could you try the users/nalcock/sol11.4 branch and see if it builds for you? (It's master, not 2.34, but I can backport if needed and if it works for you.) Solaris 11.N for earlier N also had a broken build for different reasons and is similarly fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/27967] Build failure on solaris-11 ld: fatal: option --version-script requires option -z gnu-version-script-compat to be specified
https://sourceware.org/bugzilla/show_bug.cgi?id=27967 --- Comment #5 from Nick Alcock --- Mail sent out to binutils@ for review. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/27360] libctf.so.0: undefined symbol: bsearch_r
https://sourceware.org/bugzilla/show_bug.cgi?id=27360 --- Comment #25 from Nick Alcock --- Thanks for the heads-up! -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/28545] cross compile incorrectly using host libraries in install relink
https://sourceware.org/bugzilla/show_bug.cgi?id=28545 Nick Alcock changed: What|Removed |Added CC||nick.alcock at oracle dot com Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at sourceware dot org |nick.alcock at oracle dot com Last reconfirmed||2021-11-09 --- Comment #10 from Nick Alcock --- These libraries all have no_install set: these must indeed be treated like libiberty is in 27360 and have their full path in the build tree listed before any libctf deps that transitively include them, to ensure that the right copy gets linked in, since it won't ever be installed and using an installed copy is always wrong. I'll look at it shortly. (It never occurred to me that this applied to libs other than libiberty, but it's dead obvious in hindsight.) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libctf/28545] cross compile incorrectly using host libraries in install relink
https://sourceware.org/bugzilla/show_bug.cgi?id=28545 Nick Alcock changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #11 from Nick Alcock --- Hm. This is not easy to replicate. A straight cross build, even one with --prefix=/usr and --disable-fast-install to force relinking, does not go wrong. Looking at your compile command, what's breaking it is that something is forcing "-L/mnt/pool_ssd/code/openwrt/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-11.2.0_musl_eabi/usr/lib -L/mnt/pool_ssd/code/openwrt/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-11.2.0_musl_eabi/lib -L/mnt/pool_ssd/code/openwrt/staging_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/usr/lib/libiconv-stub/lib -Wl,-rpath-link=/mnt/pool_ssd/code/openwrt/staging_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/usr/lib/libiconv-stub/lib -L/mnt/pool_ssd/code/openwrt/staging_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/usr/lib/libintl-stub/lib" in front of the -o in the libtool command. Looking at the compile log, the openwrt build scripts are passing *this* in: LDFLAGS="-L/mnt/pool_ssd/code/openwrt/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-11.2.0_musl_eabi/usr/lib -L/mnt/pool_ssd/code/openwrt/staging_dir/toolchain-arm_cortex-a7+neon-vfpv4_gcc-11.2.0_musl_eabi/lib -znow -zrelro " This is a disaster waiting to happen (and now it has happened). You can't set up sysroots by just passing in -L arguments in LDFLAGS like this! The problem is that the resulting library search order is wrong: LDFLAGS is injected early in link lines, and libraries are searched for in order of -L arguments, so any libraries specified in -L will take precedence over any -L arguments specified by binutils's actual makefiles to find its own libraries in the build tree, and there's nothing we can do about it. -L arguments should only ever appear in LIBS, accompanying specific libraries found in nonstandard paths. The compiler should have been configured to find libraries suitably without needing a massive spray of -L arguments like this: GCC has a --sysroot argument for a reason (and --sysroot does not mess up the library search order). You should probably raise this with OpenWRT (and link to this bug). I am tempted to mark this INVALID right away, but I'll leave it as WAITING until we see what the OpenWRT people say (since they probably do a lot more cross-compiling than me, to be honest). (But I clearly need to backport bug 27360 to the 2.37 branch. I'm on that.) -- You are receiving this mail because: You are on the CC list for the bug.
