* Shared librares dependency at compile time
@ 2012-07-27 19:10 LiLy
2012-07-27 19:19 ` Ian Lance Taylor
0 siblings, 1 reply; 6+ messages in thread
From: LiLy @ 2012-07-27 19:10 UTC (permalink / raw)
To: gcc, gcc-help
Hi All,
I have two existing shared libraries liba.so, libb.so.
Liba.so depends on libb.so(liba.so is dynamically linked with libb.so
). Now I want to compile an application which uses both liba.so and
libb.so.
1. On Linux, following command can pass
gcc -Wall -o app app.c -L.. -la
Note: -lb is not specified in the command
I have several questions:
1). How is libb.so also linked actually while dynamic linking liba.so?
It seems the linker knows libb.so according to the NEEDED entry in
dynamic section of liba.so(which contains the name of libb.so)? Dynamic
symbol table is also used to resolved symbols during linkage stage of
compile, right?(since the program still can compile if the shared
libraries are stripped)
Explanation of detailed workflow is welcomed.
2) With -la or without -la
We have two choices:
i) gcc -Wall -o app app.c -L.. -la
ii) gcc -Wall -o app app.c -L.. -la -lb
Which one is more preferred?
ii) is better for me, since it can indicate the dependency clearly;
another reason is, make sure it can compile on different platforms,
which I will address in the following section.
2. On Cygwin, while, the same command can not pass
gcc -Wall -o app app.c -L.. -la
(same as on Linux, no -lb )
The error report reads like this: undefined reference to xxx(symbols defined in libb.so)
Questions:
What's the difference between gcc's behaviors on Linux and Cygwin?
Thank you,
Ly
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Shared librares dependency at compile time
2012-07-27 19:10 Shared librares dependency at compile time LiLy
@ 2012-07-27 19:19 ` Ian Lance Taylor
2012-07-27 19:56 ` LiLy
0 siblings, 1 reply; 6+ messages in thread
From: Ian Lance Taylor @ 2012-07-27 19:19 UTC (permalink / raw)
To: LiLy; +Cc: gcc, gcc-help
On Fri, Jul 27, 2012 at 12:10 PM, LiLy <xmlymt@hotmail.com> wrote:
>
> I have two existing shared libraries liba.so, libb.so.
> Liba.so depends on libb.so(liba.so is dynamically linked with libb.so
> ). Now I want to compile an application which uses both liba.so and
> libb.so.
Please never send e-mail to both gcc@gcc.gnu.org and
gcc-help@gcc.gnu.org. This message should only have gone to
gcc-help@gcc.gnu.org. Please take any followups to gcc-help only.
Thanks.
> 1. On Linux, following command can pass
> gcc -Wall -o app app.c -L.. -la
> Note: -lb is not specified in the command
>
> I have several questions:
> 1). How is libb.so also linked actually while dynamic linking liba.so?
There are two answers, one using GNU ld, one using gold.
> It seems the linker knows libb.so according to the NEEDED entry in
> dynamic section of liba.so(which contains the name of libb.so)?
That is how GNU ld works, yes.
> Dynamic
> symbol table is also used to resolved symbols during linkage stage of
> compile, right?(since the program still can compile if the shared
> libraries are stripped)
Correct.
> 2) With -la or without -la
> We have two choices:
> i) gcc -Wall -o app app.c -L.. -la
> ii) gcc -Wall -o app app.c -L.. -la -lb
> Which one is more preferred?
If your application refers to symbols in libb, then the second one is
preferred. If your application only uses symbols in liba, then the
first one is preferred. In general you should link your application
against the libraries that your application refers to directly.
> 2. On Cygwin, while, the same command can not pass
> gcc -Wall -o app app.c -L.. -la
> (same as on Linux, no -lb )
> The error report reads like this: undefined reference to xxx(symbols defined in libb.so)
>
> Questions:
> What's the difference between gcc's behaviors on Linux and Cygwin?
The shared library implementations on GNU/Linux and cygwin are
completely different.
Ian
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Shared librares dependency at compile time
2012-07-27 19:19 ` Ian Lance Taylor
@ 2012-07-27 19:56 ` LiLy
2012-07-27 20:11 ` Ian Lance Taylor
0 siblings, 1 reply; 6+ messages in thread
From: LiLy @ 2012-07-27 19:56 UTC (permalink / raw)
To: iant; +Cc: gcc-help
Hi Ian,
Thanks for your quick reply!
Sorry, It's the first time for me to post to gcc mailing list. I have removed gcc@gcc.gnu.org now.
Glad to get your confirmations. Further more, could you please give me some links that introduce ld internals?
BTW, I guess gold means google ld. Regarding 1.1), I suppose gold will also work in similar way, since the obj/lib file formats are same.
Best Regards,
Ly
----------------------------------------
> Date: Fri, 27 Jul 2012 12:19:26 -0700
> Subject: Re: Shared librares dependency at compile time
> From: iant@google.com
> To: xmlymt@hotmail.com
> CC: gcc@gcc.gnu.org; gcc-help@gcc.gnu.org
>
> On Fri, Jul 27, 2012 at 12:10 PM, LiLy <xmlymt@hotmail.com> wrote:
>>
>> I have two existing shared libraries liba.so, libb.so.
>> Liba.so depends on libb.so(liba.so is dynamically linked with libb.so
>> ). Now I want to compile an application which uses both liba.so and
>> libb.so.
>
>
> Please never send e-mail to both gcc@gcc.gnu.org and
> gcc-help@gcc.gnu.org. This message should only have gone to
> gcc-help@gcc.gnu.org. Please take any followups to gcc-help only.
> Thanks.
>
>
>> 1. On Linux, following command can pass
>> gcc -Wall -o app app.c -L.. -la
>> Note: -lb is not specified in the command
>>
>> I have several questions:
>> 1). How is libb.so also linked actually while dynamic linking liba.so?
>
> There are two answers, one using GNU ld, one using gold.
>
>> It seems the linker knows libb.so according to the NEEDED entry in
>> dynamic section of liba.so(which contains the name of libb.so)?
>
> That is how GNU ld works, yes.
>
>> Dynamic
>> symbol table is also used to resolved symbols during linkage stage of
>> compile, right?(since the program still can compile if the shared
>> libraries are stripped)
>
> Correct.
>
>> 2) With -la or without -la
>> We have two choices:
>> i) gcc -Wall -o app app.c -L.. -la
>> ii) gcc -Wall -o app app.c -L.. -la -lb
>> Which one is more preferred?
>
> If your application refers to symbols in libb, then the second one is
> preferred. If your application only uses symbols in liba, then the
> first one is preferred. In general you should link your application
> against the libraries that your application refers to directly.
>
>
>> 2. On Cygwin, while, the same command can not pass
>> gcc -Wall -o app app.c -L.. -la
>> (same as on Linux, no -lb )
>> The error report reads like this: undefined reference to xxx(symbols defined in libb.so)
>>
>> Questions:
>> What's the difference between gcc's behaviors on Linux and Cygwin?
>
> The shared library implementations on GNU/Linux and cygwin are
> completely different.
>
> Ian
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: Shared librares dependency at compile time
2012-07-27 19:56 ` LiLy
@ 2012-07-27 20:11 ` Ian Lance Taylor
2012-07-27 20:23 ` LiLy
0 siblings, 1 reply; 6+ messages in thread
From: Ian Lance Taylor @ 2012-07-27 20:11 UTC (permalink / raw)
To: LiLy; +Cc: gcc-help
On Fri, Jul 27, 2012 at 12:56 PM, LiLy <xmlymt@hotmail.com> wrote:
>
> Glad to get your confirmations. Further more, could you please give me some links that introduce ld internals?
I'm fond of http://www.airs.com/blog/archives/38 and subsequent entries.
> BTW, I guess gold means google ld. Regarding 1.1), I suppose gold will also work in similar way, since the obj/lib file formats are same.
gold isn't google ld, it's just gold. it's a new linker that is part
of the GNU binutils.
There is a key difference between GNU ld and gold in this area. If
you link against liba.so, and liba.so has a DT_NEEDED entry pointing
to libb.so, then GNU ld will attempt to replicate the dynamic linker's
search path and find libb.so. gold will not do that. Because of
that, GNU ld by default will warn about undefined symbols in liba.so,
while gold by default will not.
It is quite rare for this difference to actually matter.
Ian
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Shared librares dependency at compile time
2012-07-27 20:11 ` Ian Lance Taylor
@ 2012-07-27 20:23 ` LiLy
2012-07-27 20:30 ` LiLy
0 siblings, 1 reply; 6+ messages in thread
From: LiLy @ 2012-07-27 20:23 UTC (permalink / raw)
To: iant; +Cc: gcc-help
Hi Ian,
Thanks for sharing!
Just found a discussion on GNU ld and gold.
http://code.google.com/p/mclinker/wiki/RelatedWork
Best Regards,
Ly
----------------------------------------
> Date: Fri, 27 Jul 2012 13:10:58 -0700
> Subject: Re: Shared librares dependency at compile time
> From: iant@google.com
> To: xmlymt@hotmail.com
> CC: gcc-help@gcc.gnu.org
>
> On Fri, Jul 27, 2012 at 12:56 PM, LiLy <xmlymt@hotmail.com> wrote:
> >
> > Glad to get your confirmations. Further more, could you please give me some links that introduce ld internals?
>
> I'm fond of http://www.airs.com/blog/archives/38 and subsequent entries.
>
> > BTW, I guess gold means google ld. Regarding 1.1), I suppose gold will also work in similar way, since the obj/lib file formats are same.
>
> gold isn't google ld, it's just gold. it's a new linker that is part
> of the GNU binutils.
>
> There is a key difference between GNU ld and gold in this area. If
> you link against liba.so, and liba.so has a DT_NEEDED entry pointing
> to libb.so, then GNU ld will attempt to replicate the dynamic linker's
> search path and find libb.so. gold will not do that. Because of
> that, GNU ld by default will warn about undefined symbols in liba.so,
> while gold by default will not.
>
> It is quite rare for this difference to actually matter.
>
> Ian
^ permalink raw reply [flat|nested] 6+ messages in thread
* RE: Shared librares dependency at compile time
2012-07-27 20:23 ` LiLy
@ 2012-07-27 20:30 ` LiLy
0 siblings, 0 replies; 6+ messages in thread
From: LiLy @ 2012-07-27 20:30 UTC (permalink / raw)
To: iant; +Cc: gcc-help
On the website you just sent, there are many articles by you. Really worth reading.
I've bookmarked your website. Thanks!
----------------------------------------
> From: xmlymt@hotmail.com
> To: iant@google.com
> CC: gcc-help@gcc.gnu.org
> Subject: RE: Shared librares dependency at compile time
> Date: Fri, 27 Jul 2012 20:22:47 +0000
>
>
> Hi Ian,
>
> Thanks for sharing!
>
> Just found a discussion on GNU ld and gold.
> http://code.google.com/p/mclinker/wiki/RelatedWork
>
> Best Regards,
> Ly
> ----------------------------------------
> > Date: Fri, 27 Jul 2012 13:10:58 -0700
> > Subject: Re: Shared librares dependency at compile time
> > From: iant@google.com
> > To: xmlymt@hotmail.com
> > CC: gcc-help@gcc.gnu.org
> >
> > On Fri, Jul 27, 2012 at 12:56 PM, LiLy <xmlymt@hotmail.com> wrote:
> > >
> > > Glad to get your confirmations. Further more, could you please give me some links that introduce ld internals?
> >
> > I'm fond of http://www.airs.com/blog/archives/38 and subsequent entries.
> >
> > > BTW, I guess gold means google ld. Regarding 1.1), I suppose gold will also work in similar way, since the obj/lib file formats are same.
> >
> > gold isn't google ld, it's just gold. it's a new linker that is part
> > of the GNU binutils.
> >
> > There is a key difference between GNU ld and gold in this area. If
> > you link against liba.so, and liba.so has a DT_NEEDED entry pointing
> > to libb.so, then GNU ld will attempt to replicate the dynamic linker's
> > search path and find libb.so. gold will not do that. Because of
> > that, GNU ld by default will warn about undefined symbols in liba.so,
> > while gold by default will not.
> >
> > It is quite rare for this difference to actually matter.
> >
> > Ian
>
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2012-07-27 20:30 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-07-27 19:10 Shared librares dependency at compile time LiLy
2012-07-27 19:19 ` Ian Lance Taylor
2012-07-27 19:56 ` LiLy
2012-07-27 20:11 ` Ian Lance Taylor
2012-07-27 20:23 ` LiLy
2012-07-27 20:30 ` LiLy
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).