Quantcast

Are the redundancies when specifiyng linker libs necessary?

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Are the redundancies when specifiyng linker libs necessary?

Andreas Falkenhahn
When using configure to generate makefiles I often see lots of redundancies in the final
makefiles when it comes to linking all objects into an executable.

Consider this linker line for the "Widgets" sample:

g++ -o widgets ...lots of objects here... -L/home/foo/bar/wxWidgets-3.1.0/buildgtk/lib -pthread -lwx_gtk2u_adv-3.1 -lwx_gtk2u_core-3.1 -lwx_baseu-3.1 -lwxtiff-3.1 -lwxjpeg-3.1 -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lX11 -lXxf86vm -lSM -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lglib-2.0 -lpng -lz -lwxregexu-3.1 -pthread -lz -ldl -lm -lz -ldl -lm

I can see that -pthread is in that line three times, -lz can be found three
times as well, -ldl -lm is in there twice and also there are lots of other
redundancies like -lgdk-x11-2.0 being in there twice and so on.

So are these redundancies really necessary or could I just go and remove all
doublets from that line without causing any harm?

--
Best regards,
 Andreas Falkenhahn                          mailto:[hidden email]

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Are the redundancies when specifiyng linker libs necessary?

Simon Richter
Hi,

On 13.04.2017 11:53, Andreas Falkenhahn wrote:

> When using configure to generate makefiles I often see lots of redundancies in the final
> makefiles when it comes to linking all objects into an executable.
>
> Consider this linker line for the "Widgets" sample:

> g++ -o widgets ...lots of objects here... -L/home/foo/bar/wxWidgets-3.1.0/buildgtk/lib -pthread -lwx_gtk2u_adv-3.1 -lwx_gtk2u_core-3.1 -lwx_baseu-3.1 -lwxtiff-3.1 -lwxjpeg-3.1 -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lX11 -lXxf86vm -lSM -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lglib-2.0 -lpng -lz -lwxregexu-3.1 -pthread -lz -ldl -lm -lz -ldl -lm

> I can see that -pthread is in that line three times, -lz can be found three
> times as well, -ldl -lm is in there twice and also there are lots of other
> redundancies like -lgdk-x11-2.0 being in there twice and so on.

"-pthread" is filtered in the gcc frontend to a preprocessor flag
"-D_REENTRANT" and a linker flag "-lpthread".

> So are these redundancies really necessary or could I just go and remove all
> doublets from that line without causing any harm?

You can remove them manually, but it won't give you a measurable
performance boost. In a dynamic link, ld will find out that the library
is already linked and ignore the extra mention, and in a static link, it
will try to resolve the currently unresolved symbols another time
against the symbol index in this library. If any new symbols can be
found, then the reference isn't unneeded at this point (but an earlier
instance might have been omitted), otherwise it is a fairly quick
comparison of a wordlist against a hashtable, which is negligible to the
actual linking and relocation passes later.

Automatically removing these is more difficult, as order matters in
static links. Basically, the configure script that collects them would
need to merge them instead of appending, preserving order and already
existing duplicates (that are needed for circular references) in a
single instance. Unless you are linking thousands of programs against
the same libraries, the effort to do that (keep in mind this needs to be
portable shell code) exceeds that of the linker here.

The easiest merge implementation I could think of would be to diff the
current list of libraries to be linked and the new one, and then take
all old,new and unchanged lines as the new list, i.e.

-lfoo
-lbar
-lfoo
-lbaz

first merge has all of these lines as new, so all are taken over verbatim.

-lbar
-lbaz

Two old, two unchanged lines. List of libraries is unchanged.

-lbaz
-lfoo

Three old, one unchanged, one new. Another copy of -lfoo is appended.

... and so on.

So, it is somewhat required, and getting rid of it is not worth it.

(and yes, that was a fun problem)

   Simon

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Are the redundancies when specifiyng linker libs necessary?

Andreas Falkenhahn
On 14.04.2017 at 02:20 Simon Richter wrote:

> Hi,

> On 13.04.2017 11:53, Andreas Falkenhahn wrote:

>> When using configure to generate makefiles I often see lots of redundancies in the final
>> makefiles when it comes to linking all objects into an executable.

>> Consider this linker line for the "Widgets" sample:

>> g++ -o widgets ...lots of objects here... -L/home/foo/bar/wxWidgets-3.1.0/buildgtk/lib -pthread -lwx_gtk2u_adv-3.1 -lwx_gtk2u_core-3.1 -lwx_baseu-3.1 -lwxtiff-3.1 -lwxjpeg-3.1 -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgthread-2.0 -lrt -lglib-2.0 -lX11 -lXxf86vm -lSM -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lglib-2.0 -lpng -lz -lwxregexu-3.1 -pthread -lz -ldl -lm -lz -ldl -lm

>> I can see that -pthread is in that line three times, -lz can be found three
>> times as well, -ldl -lm is in there twice and also there are lots of other
>> redundancies like -lgdk-x11-2.0 being in there twice and so on.

> "-pthread" is filtered in the gcc frontend to a preprocessor flag
> "-D_REENTRANT" and a linker flag "-lpthread".

>> So are these redundancies really necessary or could I just go and remove all
>> doublets from that line without causing any harm?

> You can remove them manually, but it won't give you a measurable
> performance boost. In a dynamic link, ld will find out that the library
> is already linked and ignore the extra mention, and in a static link, it
> will try to resolve the currently unresolved symbols another time
> against the symbol index in this library. If any new symbols can be
> found, then the reference isn't unneeded at this point (but an earlier
> instance might have been omitted), otherwise it is a fairly quick
> comparison of a wordlist against a hashtable, which is negligible to the
> actual linking and relocation passes later.

> Automatically removing these is more difficult, as order matters in
> static links. Basically, the configure script that collects them would
> need to merge them instead of appending, preserving order and already
> existing duplicates (that are needed for circular references) in a
> single instance. Unless you are linking thousands of programs against
> the same libraries, the effort to do that (keep in mind this needs to be
> portable shell code) exceeds that of the linker here.

> The easiest merge implementation I could think of would be to diff the
> current list of libraries to be linked and the new one, and then take
> all old,new and unchanged lines as the new list, i.e.

> -lfoo
> -lbar
> -lfoo
> -lbaz

> first merge has all of these lines as new, so all are taken over verbatim.

> -lbar
> -lbaz

> Two old, two unchanged lines. List of libraries is unchanged.

> -lbaz
> -lfoo

> Three old, one unchanged, one new. Another copy of -lfoo is appended.

> ... and so on.

> So, it is somewhat required, and getting rid of it is not worth it.

> (and yes, that was a fun problem)

Thanks a lot for the explanations! I've already asked this question on
Stack Overflow before but haven't received an answer. See here:
http://stackoverflow.com/questions/43369242/are-the-redundancies-when-specifying-linker-libs-necessary 

If you have an account at Stack Overflow, you might just want to copy
& paste it there and I'll mark it as accepted. Otherwise I can also
do this, giving credit to you of course.

--
Best regards,
 Andreas Falkenhahn                            mailto:[hidden email]

--
Please read http://www.wxwidgets.org/support/mlhowto.htm before posting.

To unsubscribe, send email to [hidden email]
or visit http://groups.google.com/group/wx-users
Loading...