ld-elf2flt: behave properly when called with a name different from TA… #8
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…RGET_ALIAS ld-elf2flt currently handles two cases: 1 It is called as the wrapper for <TARGET_ALIAS>-ld, generally installed in the bin/ directory of a toolchain. 2 It is called as the wrapper for "ld", generally installed in the TARGET_ALIAS/bin/ directory of a toolchain. Unfortunately, if for some reason it gets called using a FOOBAR-ld name that is different from <TARGET_ALIAS>-ld, it assumes it is in case (2), while it really is in case (1). Due to this, the path mangling logic doesn't work, and it doesn't find ld.real. This happens for example when the binary program in bin/ is named arm-buildroot-uclinux-uclibcgnueabi-ld, but also has a simpler symlink named arm-linux-ld. In this case, arm-buildroot-uclinux-uclibcgnueabi-ld is recognized by ld-elf2flt as containing TARGET_ALIAS, and therefore the proper logic to find ld.real is applied. However, when arm-linux-ld is used, ld-elf2flt doesn't find TARGET_ALIAS, and therefore assumes we're being called as TARGET_ALIAS/bin/ld.. and searches for a program called ld.real in bin/, which doesn't exist. See: $ ./output/host/bin/arm-buildroot-uclinux-uclibcgnueabi-ld /home/thomas/buildroot/buildroot/output/host/bin/../arm-buildroot-uclinux-uclibcgnueabi/bin/ld.real: no input files $ ./output/host/bin/arm-linux-ld arm-linux-ld (ld-elf2flt): error trying to exec '/home/thomas/buildroot/buildroot/output/host/bin/ld.real': execvp: No such file or directory $ ./output/host/arm-buildroot-uclinux-uclibcgnueabi/bin/ld /home/thomas/buildroot/buildroot/output/host/arm-buildroot-uclinux-uclibcgnueabi/bin/ld.real: no input files This commit fixes that by inverting the logic: if we're being called as just "ld", then we assume it's the program in TARGET_ALIAS/bin/. Otherwise, we're called through some variant of TARGET-ld. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
RomainNaour
added a commit
to RomainNaour/buildroot
that referenced
this pull request
Mar 10, 2019
Binutils added bfd_stdint.h to bfd.h [1], so elf2flt must create a symlink for this header. Bump the elf2flt version that include the upstream fix [2]. Keep our local patch 0001-ld-elf2flt-behave-properly-when-called-with-a-name-d.patch that was not integrated with the recent project activity [3]. Fixes: [armv7m-uclibc] https://gitlab.com/kubu93/toolchains-builder/-/jobs/148356410 [m68k-coldfire-uclibc] https://gitlab.com/kubu93/toolchains-builder/-/jobs/148356412 [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=2d5d5a8f0a8b5a03454bf168b7fa7024bb1ebbd8 [2] uclinux-dev/elf2flt@429521f [3] uclinux-dev/elf2flt#8 Signed-off-by: Romain Naour <romain.naour@gmail.com> --- v2: bump the version instead of adding a new local patch (Arnout).
|
@vapier any chance to get this reviewed/applied ? Thanks! |
buildroot-auto-update
pushed a commit
to buildroot/buildroot
that referenced
this pull request
Mar 12, 2019
Binutils added bfd_stdint.h to bfd.h [1], so elf2flt must create a symlink for this header. This issue has been fixed upstream in commit [2]. We keep our local patch 0001-ld-elf2flt-behave-properly-when-called-with-a-name-d.patch as it still hasn't been merged upstream [3]. Fixes (with binutils 2.23): [armv7m-uclibc] https://gitlab.com/kubu93/toolchains-builder/-/jobs/148356410 [m68k-coldfire-uclibc] https://gitlab.com/kubu93/toolchains-builder/-/jobs/148356412 [1] https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commitdiff;h=2d5d5a8f0a8b5a03454bf168b7fa7024bb1ebbd8 [2] uclinux-dev/elf2flt@429521f [3] uclinux-dev/elf2flt#8 Signed-off-by: Romain Naour <romain.naour@gmail.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
|
thx bud. fell through the cracks ... a few times. |
damien-lemoal
pushed a commit
to damien-lemoal/elf2flt
that referenced
this pull request
Apr 21, 2022
…RGET_ALIAS ld-elf2flt currently handles two cases: 1 It is called as the wrapper for <TARGET_ALIAS>-ld, generally installed in the bin/ directory of a toolchain. 2 It is called as the wrapper for "ld", generally installed in the TARGET_ALIAS/bin/ directory of a toolchain. Unfortunately, if for some reason it gets called using a FOOBAR-ld name that is different from <TARGET_ALIAS>-ld, it assumes it is in case (2), while it really is in case (1). Due to this, the path mangling logic doesn't work, and it doesn't find ld.real. This happens for example when the binary program in bin/ is named arm-buildroot-uclinux-uclibcgnueabi-ld, but also has a simpler symlink named arm-linux-ld. In this case, arm-buildroot-uclinux-uclibcgnueabi-ld is recognized by ld-elf2flt as containing TARGET_ALIAS, and therefore the proper logic to find ld.real is applied. However, when arm-linux-ld is used, ld-elf2flt doesn't find TARGET_ALIAS, and therefore assumes we're being called as TARGET_ALIAS/bin/ld.. and searches for a program called ld.real in bin/, which doesn't exist. See: $ ./output/host/bin/arm-buildroot-uclinux-uclibcgnueabi-ld /home/thomas/buildroot/buildroot/output/host/bin/../arm-buildroot-uclinux-uclibcgnueabi/bin/ld.real: no input files $ ./output/host/bin/arm-linux-ld arm-linux-ld (ld-elf2flt): error trying to exec '/home/thomas/buildroot/buildroot/output/host/bin/ld.real': execvp: No such file or directory $ ./output/host/arm-buildroot-uclinux-uclibcgnueabi/bin/ld /home/thomas/buildroot/buildroot/output/host/arm-buildroot-uclinux-uclibcgnueabi/bin/ld.real: no input files This commit fixes that by inverting the logic: if we're being called as just "ld", then we assume it's the program in TARGET_ALIAS/bin/. Otherwise, we're called through some variant of TARGET-ld. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com> Submitted-upstream: uclinux-dev#8
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
…RGET_ALIAS
ld-elf2flt currently handles two cases:
1 It is called as the wrapper for <TARGET_ALIAS>-ld, generally
installed in the bin/ directory of a toolchain.
2 It is called as the wrapper for "ld", generally installed in the
TARGET_ALIAS/bin/ directory of a toolchain.
Unfortunately, if for some reason it gets called using a FOOBAR-ld
name that is different from <TARGET_ALIAS>-ld, it assumes it is in
case (2), while it really is in case (1). Due to this, the path
mangling logic doesn't work, and it doesn't find ld.real.
This happens for example when the binary program in bin/ is named
arm-buildroot-uclinux-uclibcgnueabi-ld, but also has a simpler symlink
named arm-linux-ld. In this case,
arm-buildroot-uclinux-uclibcgnueabi-ld is recognized by ld-elf2flt as
containing TARGET_ALIAS, and therefore the proper logic to find
ld.real is applied. However, when arm-linux-ld is used, ld-elf2flt
doesn't find TARGET_ALIAS, and therefore assumes we're being called as
TARGET_ALIAS/bin/ld.. and searches for a program called ld.real in
bin/, which doesn't exist.
See:
$ ./output/host/bin/arm-buildroot-uclinux-uclibcgnueabi-ld
/home/thomas/buildroot/buildroot/output/host/bin/../arm-buildroot-uclinux-uclibcgnueabi/bin/ld.real: no input files
$ ./output/host/bin/arm-linux-ld
arm-linux-ld (ld-elf2flt): error trying to exec '/home/thomas/buildroot/buildroot/output/host/bin/ld.real': execvp: No such file or directory
$ ./output/host/arm-buildroot-uclinux-uclibcgnueabi/bin/ld
/home/thomas/buildroot/buildroot/output/host/arm-buildroot-uclinux-uclibcgnueabi/bin/ld.real: no input files
This commit fixes that by inverting the logic: if we're being called
as just "ld", then we assume it's the program in
TARGET_ALIAS/bin/. Otherwise, we're called through some variant of
TARGET-ld.
Signed-off-by: Thomas Petazzoni thomas.petazzoni@free-electrons.com