tech-toolchain archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: "Fixing" new ld(1) DT_NEEDED handling

On Mon, Oct 14, 2013 at 15:10:47 +0200, Martin Husemann wrote:

> On Mon, Oct 14, 2013 at 04:59:34PM +0400, Valery Ushakov wrote:
> > I'm still confused.  The observed beahviour (see one of my previous
> > mails) is that solaris ld does NOT resolve symbols from implicit
> > dependencies.  I.e. the new gnu ld behaviour matches solaris ld.
> You quoted:
> | If a shared object has dependencies on other shared objects, these
> | dependencies can also be processed.  This processing occurs after
> | all command line input files have been processed, to complete the
> | symbol resolution process.  However, the shared object names are not
> | recorded as dependencies in the output file image being generated.
> I read this as: the indirect symbols are resolved but no DT_NEEDED
> entries generated.

And then I wrote:

| Hmm, using
| example on Solaris 11:
| $ gcc --verbose -o foo1 foo1.o -L.
| [...]
| ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.2324
| Undefined   first referenced
|  symbol         in file
| foo         foo1.o  (symbol belongs to implicit dependency ./
| ld: fatal: symbol referencing errors. No output written to foo1

So the symbol is NOT resolved.

Does OpenSolaris use gnu binutils, btw?  I wonder why pkgsrc hasn't
hit these problems on Solaris as well.

> > If we fix link commands to provide explicit dependencies, that will
> > work with both old behaviour and new behaviour, won't it?
> Yes, after fixing the fallout (which I expected to be bigger).


Home | Main Index | Thread Index | Old Index