Simple linking problem

Simple linking problem

[gccNewbie]

After spending years working in Java, I've decided I'd like to do a little C
programming. I've gotten gcc, which I think is the first step. In fact, I'm
using an old version, 3.2.3 for MinGW. I've done "Hello world" just to be
sure gcc is working. Now I'm trying to get gcc to link.

I've studed all the options, all the ways to invoke gcc, and I can find
nothing helpful. I've got a library in a file starting with 'lib' and ending
with '.a'. I've downloaded this file from the web, I've downloaded the
source and used the makefile to compile the library. It seems that no matter
what I do I cannot get gcc to treat this file as a library containing the
stuff that I am absolutely sure it is supposed to contain.

I know gcc is finding the file. If I go "gcc -lblah" and it cannot find
libblah.a, it will give me an error that tells me the library wasn't found.
So the library file is found. I see nothing in the documentation that
suggests I should need to do anything more than "gcc -lmylib test.c" to
compile 'test.c' with the functions defined in mylib. I have the library, I
tell gcc to use the library, and yet it acts as though these library
functions are undefined, giving 'undefined reference to' messages.

I've looked at all the documentation I can think to study without finding
any possible solution. Is there any way to get gcc to tell me exactly what
is really in the library file? I can use 'ar' to discover the file names
that make up the library, but I'd like to know the function names that are
in there so I can tell if gcc is to blame or if the library really doesn't
have the things that gcc says it doesn't have.

This has got to be a simple problem. I'd just like a hint about where to
look for the cause. What do you do when gcc tells you that something is
undefined even though you know that it's defined?
-- 
View this message in context: http://www.nabble.com/Simple-linking-problem-tf3720892.html#a10410954
Sent from the gcc - Help mailing list archive at Nabble.com.

Re: Simple linking problem

[Andrew Haley]

gccNewbie writes:
 > 
 > After spending years working in Java, I've decided I'd like to do a little C
 > programming. I've gotten gcc, which I think is the first step. In fact, I'm
 > using an old version, 3.2.3 for MinGW. I've done "Hello world" just to be
 > sure gcc is working. Now I'm trying to get gcc to link.
 > 
 > I've studed all the options, all the ways to invoke gcc, and I can find
 > nothing helpful. I've got a library in a file starting with 'lib' and ending
 > with '.a'. I've downloaded this file from the web, I've downloaded the
 > source and used the makefile to compile the library. It seems that no matter
 > what I do I cannot get gcc to treat this file as a library containing the
 > stuff that I am absolutely sure it is supposed to contain.
 > 
 > I know gcc is finding the file. If I go "gcc -lblah" and it cannot find
 > libblah.a, it will give me an error that tells me the library wasn't found.
 > So the library file is found. I see nothing in the documentation that
 > suggests I should need to do anything more than "gcc -lmylib test.c" to
 > compile 'test.c' with the functions defined in mylib. I have the library, I
 > tell gcc to use the library, and yet it acts as though these library
 > functions are undefined, giving 'undefined reference to' messages.
 > 
 > I've looked at all the documentation I can think to study without finding
 > any possible solution. Is there any way to get gcc to tell me exactly what
 > is really in the library file?

Yes.  The command is called "nm".

Andrew.

Re: Simple linking problem

[gccNewbie]

Andrew Haley-5 wrote:
> 
> Yes.  The command is called "nm".
> 

Thanks. It seems to often happen that what you are looking for is in the
last place you look. Usually you ask for help online just before looking in
that last place, too. I discovered nm mere minutes after asking my question.

Unfortunately, nm merely confirmed what I already knew. It has some rather
complicated output, but the names of these so-called undefined functions are
in the library, right next to a T which should mean that the library
provides a definition of these functions.

So it is really a very simple riddle. 'gcc -lmylib mysource.c' uses a
function 'foo' which nm shows is defined in libmylib.a. gcc does not
complain about not being able to find mylib, but it does complain that 'foo'
is an 'undefined reference'. In what situation could that happen?
-- 
View this message in context: http://www.nabble.com/Simple-linking-problem-tf3720892.html#a10411665
Sent from the gcc - Help mailing list archive at Nabble.com.

RE: Simple linking problem

[John (Eljay) Love-Jensen]

Hi gccNewbie,

>So it is really a very simple riddle. 'gcc -lmylib mysource.c' uses a function 'foo' which nm shows is defined in libmylib.a. gcc does not complain about not being able to find mylib, but it does complain that 'foo' is an 'undefined reference'. In what situation could that happen?

Dependency order is important.

What happens when you do:

gcc mysource.c -lmylib

HTH,
--Eljay

Re: Simple linking problem

[Andrew Haley]

gccNewbie writes:
 > 
 > 
 > Andrew Haley-5 wrote:
 > > 
 > > Yes.  The command is called "nm".
 > > 
 > 
 > Thanks. It seems to often happen that what you are looking for is in the
 > last place you look. Usually you ask for help online just before looking in
 > that last place, too. I discovered nm mere minutes after asking my question.
 > 
 > Unfortunately, nm merely confirmed what I already knew. It has some rather
 > complicated output, but the names of these so-called undefined functions are
 > in the library, right next to a T which should mean that the library
 > provides a definition of these functions.
 > 
 > So it is really a very simple riddle. 'gcc -lmylib mysource.c' uses a
 > function 'foo' which nm shows is defined in libmylib.a. gcc does not
 > complain about not being able to find mylib, but it does complain that 'foo'
 > is an 'undefined reference'. In what situation could that happen?

Maybe link ordering, maybe link paths.

if it's link ordering, 'gcc -lmylib mysource.c -lmylib' will fix it.
If it's link paths, you need '-L.'

If neither of those work, we need to start debugging.

Andrew.

Re: Simple linking problem

[Matthew Woehlke]

gccNewbie wrote:
> So it is really a very simple riddle. 'gcc -lmylib mysource.c' uses a
> function 'foo' which nm shows is defined in libmylib.a. gcc does not
> complain about not being able to find mylib, but it does complain that 'foo'
> is an 'undefined reference'. In what situation could that happen?

Linux lets you get away with this wrong link order due to lazy symbol 
resolution, whereas Windows does not. What you have done is asked to 
first link to libmylib. Since no objects (actually, you don't *have* any 
objects yet!) require any symbols from libmylib, no symbols are 
imported. Next you have asked to link 'mysource.c' (which is first 
compiled to object form, of course), which has unresolved symbols. And 
now you are at the end of the link step with unresolved symbols, which 
are not permitted on Windows.

The correct order is to first compile/link 'mysource.c', which (as 
expected) has unresolved symbols, and /then/ to link 'libmylib' which 
contains the unresolved symbols. Now when you reach the end of the list 
of things to link, you do not have unresolved symbols, and so you can 
successfully produce a binary.

-- 
Matthew
"Ah, yes. Control the media and you control the world."
   -- from a story by Raven Blackmane

Re: Simple linking problem

[gccNewbie]

Matthew Woehlke-3 wrote:
> 
> Linux lets you get away with this wrong link order due to lazy symbol 
> resolution, whereas Windows does not. What you have done is asked to 
> first link to libmylib. Since no objects (actually, you don't *have* any 
> objects yet!) require any symbols from libmylib, no symbols are 
> imported. 
> 

That solved my problem very well! I should have tried that, but it's even
better to have this explanation of why it works.

It's odd that the manual was so deliberately misleading on this! While I was
trying to solve this myself, I read: "You can mix options and other
arguments. For the most part, the order you use doesn't matter. Order does
matter when you use several options of the same kind; for example, if you
specify -L more than once, the directories are searched in the order
specified."
-- 
View this message in context: http://www.nabble.com/Simple-linking-problem-tf3720892.html#a10418803
Sent from the gcc - Help mailing list archive at Nabble.com.

Doc is misleading (was: Simple linking problem)

[Matthew Woehlke]

gccNewbie wrote:
> Matthew Woehlke-3 wrote:
>> Linux lets you get away with this wrong link order due to lazy symbol 
>> resolution, whereas Windows does not. What you have done is asked to 
>> first link to libmylib. Since no objects (actually, you don't *have* any 
>> objects yet!) require any symbols from libmylib, no symbols are 
>> imported. 
> 
> That solved my problem very well! I should have tried that, but it's even
> better to have this explanation of why it works.

Glad it was helpful! :-)

> It's odd that the manual was so deliberately misleading on this! While I was
> trying to solve this myself, I read: "You can mix options and other
> arguments. For the most part, the order you use doesn't matter. Order does
> matter when you use several options of the same kind; for example, if you
> specify -L more than once, the directories are searched in the order
> specified."

Eeeeeeeh... *technically* it isn't wrong (you can mix -W, -f options, 
for example) but I see why it confused you, and I agree that it *really* 
ought to say something about -l being in the 'order can matter' 
category. You are by no means the first person on Windows to get bitten 
by this.

To whoever maintains the doc: we really should add something like "Note 
that the order of objects, including libraries specified by -l, DOES 
matter on some platforms.", perhaps with an even longer explanation as 
well such as what was in my previous post.

-- 
Matthew
"Ah, yes. Control the media and you control the world."
   -- from a story by Raven Blackmane

Re: Doc is misleading

[David Daney]

Matthew Woehlke wrote:
> gccNewbie wrote:
>> Matthew Woehlke-3 wrote:
>>> Linux lets you get away with this wrong link order due to lazy symbol 
>>> resolution, whereas Windows does not. What you have done is asked to 
>>> first link to libmylib. Since no objects (actually, you don't *have* 
>>> any objects yet!) require any symbols from libmylib, no symbols are 
>>> imported. 
>>
>> That solved my problem very well! I should have tried that, but it's even
>> better to have this explanation of why it works.
> 
> Glad it was helpful! :-)
> 
>> It's odd that the manual was so deliberately misleading on this! While 
>> I was
>> trying to solve this myself, I read: "You can mix options and other
>> arguments. For the most part, the order you use doesn't matter. Order 
>> does
>> matter when you use several options of the same kind; for example, if you
>> specify -L more than once, the directories are searched in the order
>> specified."
> 
> Eeeeeeeh... *technically* it isn't wrong (you can mix -W, -f options, 
> for example) but I see why it confused you, and I agree that it *really* 
> ought to say something about -l being in the 'order can matter' 
> category. You are by no means the first person on Windows to get bitten 
> by this.
> 
> To whoever maintains the doc: we really should add something like "Note 
> that the order of objects, including libraries specified by -l, DOES 
> matter on some platforms.", perhaps with an even longer explanation as 
> well such as what was in my previous post.

Perhaps reading this would be helpful:

http://sourceware.org/binutils/docs-2.17/ld/Options.html

I think it explains how it works.

David Daney

Re: Doc is misleading

[Matthew Woehlke]

David Daney wrote:
> Matthew Woehlke wrote:
>> To whoever maintains the doc: we really should add something like 
>> "Note that the order of objects, including libraries specified by -l, 
>> DOES matter on some platforms.", perhaps with an even longer 
>> explanation as well such as what was in my previous post.
> 
> Perhaps reading this would be helpful:
> 
> http://sourceware.org/binutils/docs-2.17/ld/Options.html
> 
> I think it explains how it works.

I don't care if it gives a 500 page dissertation on the meaning of life. 
:-) 'info gcc' says this:

<quote>
  You can mix options and other arguments.  For the most part, the order
you use doesn't matter.  Order does matter when you use several options
of the same kind; for example, if you specify `-L' more than once, the
directories are searched in the order specified.
</quote>

...which IMO is misleading and should be fixed. While it might be nice 
if we did, I don't think it is critical that we explain things here in 
depth, as long as we /avoid/ giving the impression that no explanation 
is needed, and that things work a particular way /which is wrong/. Two 
or three sentences would be a great convenience, but even just /one/ 
could save a lot of headaches.

-- 
Matthew
"Ah, yes. Control the media and you control the world."
   -- from a story by Raven Blackmane

Re: Doc is misleading

[Ian Lance Taylor]

Matthew Woehlke <mw_triad@users.sourceforge.net> writes:

> I don't care if it gives a 500 page dissertation on the meaning of
> life. :-) 'info gcc' says this:
> 
> <quote>
>   You can mix options and other arguments.  For the most part, the order
> you use doesn't matter.  Order does matter when you use several options
> of the same kind; for example, if you specify `-L' more than once, the
> directories are searched in the order specified.
> </quote>
> 
> ...which IMO is misleading and should be fixed. While it might be nice
> if we did, I don't think it is critical that we explain things here in
> depth, as long as we /avoid/ giving the impression that no explanation
> is needed, and that things work a particular way /which is wrong/. Two
> or three sentences would be a great convenience, but even just /one/
> could save a lot of headaches.

Thanks for the suggestion.  I just committed this patch to help avoid
this problem in future releases.

http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01558.html

Ian

Re: Doc is misleading

[Matthew Woehlke]

Ian Lance Taylor wrote:
> Matthew Woehlke writes:
>> I don't care if it gives a 500 page dissertation on the meaning of
>> life. :-) 'info gcc' says this:
>>
>> <quote>
>>   You can mix options and other arguments.  For the most part, the order
>> you use doesn't matter.  Order does matter when you use several options
>> of the same kind; for example, if you specify `-L' more than once, the
>> directories are searched in the order specified.
>> </quote>
>>
>> ...which IMO is misleading and should be fixed. While it might be nice
>> if we did, I don't think it is critical that we explain things here in
>> depth, as long as we /avoid/ giving the impression that no explanation
>> is needed, and that things work a particular way /which is wrong/. Two
>> or three sentences would be a great convenience, but even just /one/
>> could save a lot of headaches.
> 
> Thanks for the suggestion.  I just committed this patch to help avoid
> this problem in future releases.
> 
> http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01558.html

Awesome, thanks Ian! I had to read it twice to fully catch it, but your 
wording "the *placement* of [-l]..." is actually a /very/ good way of 
saying this :-).

-- 
Matthew
"I can hear you / just barely hear you / I can just barely hear you"
   -- "I Can Hear You", by They Might Be Giants