------- Additional Comments From jreiser at BitWagon dot com 2008-04-29 18:54 ------- Subject: Re: ld: --export-dynamic fails if no undefined symbols
drow at false dot org wrote: > ------- Additional Comments From drow at false dot org 2008-04-29 18:14 > ------- > Subject: Re: New: ld: --export-dynamic fails if no undefined > symbols > > On Tue, Apr 29, 2008 at 05:59:42PM -0000, jreiser at BitWagon dot com wrote: > >>If there are no undefined symbols then there is no Dynamic section, no >>DT_SYMTAB, and no DT_HASH/DT_GNU_HASH; and --export-dynamic fails silently. >>So >>there is no way to have a module (ET_EXEC or ET_DYN) that has no undefined >>symbols, yet exports some of its own symbols for use by other modules. > > > I don't think this is true for ET_DYN. Have you tested that? It's > not related to undefined symbols; it's caused by not linking an > ET_EXEC against any shared libraries. Yes, adding "-shared" to the command line does give an ET_DYN module with no undefined symbols that does have a Dynamic section and DT_GNU_HASH (or DT_HASH.) But it also has DT_TEXTREL (in this case, or if any actual non-PIC code) and I wish to avoid that. I suppose I could build the module as ET_DYN with specified .p_vaddr, then use a binary editor to change the .e_type to ET_EXEC, and elide the DT_TEXTREL from the Dynamic section; then use objcopy to remove relocation sections. [Did I cover everything that should be changd? ;-)] > This is solved by the --force-dynamic option in the VxWorks port of > ld. The feature was not desired for other targets so the option is > restricted to VxWorks. It seems to me that the ability to construct a symbol table (and associated support) for some runtime global symbols should be an independent feature of ld. Some commandline parameters might force its use, and some uses might omit the table by default, but not being able to force the table is an omission. What was the specific objection to --force-dynamic on non-VxWorks? -- http://sourceware.org/bugzilla/show_bug.cgi?id=6468 ------- 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
