[devel] Q: --no-copy-dt-needed-entries

[Alexey Tourbin]

On Sun, Mar 21, 2010 at 06:34:43PM +0300, Dmitry V. Levin wrote:
> > > --no-copy-dt-needed-entries можно рассматривать как дополнение к --as-needed:
> > > 
> > > Первый параметр заставляет линковать свою программу со всеми
> > > библиотеками, котрые эта программа непосредственно использует.
> > 
> > In ld(1) manpage, perhaps the description is not quite clear.  And we
> > should strive for very accurate wording in order to avoid a total mess.
> > (E.g. we'd better avoid anthropomorphic clauses like "zastavlyaet".)
> 
> With --no-copy-dt-needed-entries in effect, each ELF output executable will
> have to be linked with every library it uses directly.

I have to indicate that "will have to be linked" and "uses directly"
is still too vague and rather anthropomorphic language.

As far as I can see, there's no definite and formal description of
what these options are supposed to do.  (I haven't looked at the source
code yet.)

> > |       --copy-dt-needed-entries
> > |       --no-copy-dt-needed-entries
> > |	   This  option  affects the treatment of dynamic libraries
> > |	   referred to by DT_NEEDED tags inside ELF dynamic libraries
> > |	   mentioned on the command line.  Normally the linker will add
> > |	   a DT_NEEDED tag to the output binary for each  library
> > |	   mentioned  in  a DT_NEEDED tag in an input dynamic library.
> > 
> > So, "normally" what's happening is something like a "shallow closure".
> > E.g. when I link with libgtk+2, glib2 is going to be linked in, too,
> > automatically.
> > 
> > |	   With --no-copy-dt-needed-entries specified on the command
> > |	   line however any dynamic libraries that follow it will have
> > |	   their DT_NEEDED entries ignored.  The default  behaviour can
> > |	   be restored with --copy-dt-needed-entries.
> > 
> > So --copy-dt-needed-entries is the default - which is to link in more
> > dependencies automatically;  --no-copy-dt-needed-entries reverts this
> > logic to its bare minimum - only what you specified on the command line
> > gets actually linked in (so you must specify e.g. both libgtk+2 and glib2).
> 
> If your application doesn't use glib2, there is no need to link with
> glib2.

Again, "using" glib2 is just a poor wording - using glib2 API calls
in the source code is not exactly the same as linking with glib2 ABI.
For example, since libgtk+2 header files include glib2 header files,
glib2 ABI calls might happen inadvertently.  This is due to macros,
static inline functions etc.  So you may not even know that you're
"using" glib2.

Remember pkg-config issues and --disable-recursion flag.
This is just it.

$ pkg-config --disable-recursion --libs gtk+-2.0
-lgtk-x11-2.0
$ pkg-config --libs gtk+-2.0                    
-lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lgdk_pixbuf-2.0 -lpangocairo-1.0 -lcairo -lpangoft2-1.0 -lpango-1.0 -lm -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lglib-2.0  
$ 

So pkg-config makes a "closure" by default, based on additional
information from package configuration files.  ld(1) now does a similar
thing, "shallow closure" based on the information from the libraries
themselves.  Also remember once you told it is possible to recover *.la
files based on the information from corresponding *.so files alone.

> > |	  This option also has an effect on the resolution of symbols in
> > |	  dynamic libraries.  With the default setting dynamic libraries
> > |	  mentioned on the command line will be recursively searched,
> > |	  following  their  DT_NEEDED  tags  to  other libraries,  in
> > |	  order to resolve symbols required by the output binary.  With
> > |	  --no-copy-dt-needed-entries specified however the searching of
> > |	  dynamic libraries that follow it will stop with the dynamic
> > |	  library itself.  No  DT_NEEDED links will be traversed to
> > |	  resolve symbols.
> > 
> > Again, "this option also has an effect on the resolution of symbols"
> > is a poor wording.  Does this option affect only DT_NEEDED entries,
> > or does it also set some other flags in the output binary?  Does this
> > paragraph address the ld(1) behaviour or rather ld.so(8) behaviour?
> 
> The abovementioned options affects the ld(1) behaviour only.

They say "No DT_NEEDED links will be traversed to resolve symbols."
This is like, cool, you know.  Shall I believe it?

> > > Второй параметр не дает слинковать свою программу с библиотеками, которые
> > > эта программа не использует непосредственно.
> > > 
> > > В результате программа должна получиться слинкованной с теми и только с
> > > теми библиотеками, которые она непосредственно использует, т.е. должна
> > > произойти правильная оптимальная линковка.
> > 
> > So, contrary to the initial message, with --as-needed on, there seems
> > to be NO REASON to enable --no-copy-dt-needed-entries by default.
> 
> Just the opposite, there is a reason to link ELF executables with all
> libraries they use directly.  Applications should be neither overlinked
> nor underlinked.  The first problem is solved by --as-needed, the second
> issue will be fixed by enabling --no-copy-dt-needed-entries by default.

Give me a good reason, with examples, why we should change the default.
There was a good reason for --as-needed - extra dependencies and extra
lookup costs.  I see no good reason for --no-copy-dt-needed-entries.
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя     : отсутствует
Тип     : application/pgp-signature
Размер  : 198 байтов
Описание: отсутствует
Url     : <http://lists.altlinux.org/pipermail/devel/attachments/20100321/d7c32872/attachment-0001.bin>