The following change, between binutils 2.18 and 2.20, removed the ability of ld's -L option to influence how linker scripts are located: http://sourceware.org/ml/binutils-cvs/2009-04/msg00044.html http://sourceware.org/ml/binutils/2009-04/msg00107.html
As far as I can tell, there is no longer a way to add to the search path for finding (for example) ldscripts/elf_i386.x, ldscripts/elf_i386.xs etc. The -T option is not a very good substitute because it only supplies a fixed linker script. When using -T, the linker will not choose between scripts according to whether an executable is being linked (elf_i386.x) or a library is being linked (elf_i386.xs), which it would do using -L. This is a partial regression. I say partial because in the past I had to disable binutils' compiling-in of linker scripts in order to use -L this way. (See http://repo.or.cz/w/nacl-binutils.git/commit/885d51de41658d6752f28c0c4c2dca56cb5e4c1c) Is there any chance of reverting this change? I don't really understand why the change was made given that it makes ld less flexible. -- Summary: -L no longer influences how ld finds linker scripts when not using -T Product: binutils Version: 2.20 Status: NEW Severity: normal Priority: P2 Component: ld AssignedTo: unassigned at sources dot redhat dot com ReportedBy: mrs at mythic-beasts dot com CC: bug-binutils at gnu dot org http://sourceware.org/bugzilla/show_bug.cgi?id=11024 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org http://lists.gnu.org/mailman/listinfo/bug-binutils
