I want to create a library of C++ objects, compiled simply as follows:
QCC -c foo.cpp
ar -r mylib.lib foo.o
This creates the library OK. But I can’t link to it. If there was a
function in foo.cpp called:
int func(void) { }
and assuming foo2.cpp calls func(), the linker can’t find it. It
returns the message:
QCC -o foo -L ./ mylib.lib foo2.cpp
undefined reference to ‘func(void)’
The linker obviously finds the library. But it can’t find the function.
What’s the trick? Is this a name mangling issue? I’m thinking that my
command lines are incomplete, but I can’t figure out in what way.
I want to create a library of C++ objects, compiled simply as follows:
QCC -c foo.cpp
ar -r mylib.lib foo.o
This creates the library OK. But I can’t link to it. If there was a
function in foo.cpp called:
int func(void) { }
and assuming foo2.cpp calls func(), the linker can’t find it. It
returns the message:
QCC -o foo -L ./ mylib.lib foo2.cpp
undefined reference to ‘func(void)’
The linker obviously finds the library. But it can’t find the function.
What’s the trick? Is this a name mangling issue? I’m thinking that my
command lines are incomplete, but I can’t figure out in what way.
Try naming your library libmylib.a and use
qcc -o foo -lmylib foo2.cpp
Make sure func() is defined in a header when copying foo2.cpp
Both of the above posters make good points that should be reiterated.
The standard way to name a library is “lib.a” (or the .so extension
in the case of shared libs). This allows one to link simply by adding a
“-l” to the compile line.
You will usually need to tell it where to look for libraries if the lib is
not in the standard locations (/lib, /usr/lib). This is the purpose of the
“-L.” flag.
The order of linking is important. Any undefined references will be
established and resolved in order so if you do g++ -o myprog
myprog.o -lmylib, where myprog references ‘foo’ which is in mylib, it will
work. However, if you did g++ -o myprog -lmylib myprog.o, it would not work
and you would get an undefined reference to foo.
Is it still an issue that if module A refers to things in module B and
module B refers to things in module A, then the library needs to be
specified twice?
The order of linking is important. Any undefined references will be
established and resolved in order so if you do g++ -o myprog
myprog.o -lmylib, where myprog references ‘foo’ which is in mylib, it will
work. However, if you did g++ -o myprog -lmylib myprog.o, it would not
work
and you would get an undefined reference to foo.
Is it still an issue that if module A refers to things in module B and
module B refers to things in module A, then the library needs to be
specified twice?
“Kris Warkentin” <> kewarken@qnx.com> > wrote in message
news:anhjui$ktv$> 1@nntp.qnx.com> …
The order of linking is important. Any undefined references will be
established and resolved in order so if you do g++ -o myprog
myprog.o -lmylib, where myprog references ‘foo’ which is in mylib, it
will
work. However, if you did g++ -o myprog -lmylib myprog.o, it would not
work
and you would get an undefined reference to foo.
\
I think it’s more of an optimization. Consider all the information that the
linker would have to hold in memory if it were going to try to resolve
forward references. Your only other option would be to make the linker do
multiple passes but, considering that linking is often the longest stage
(especially if you’re only recompiling 1 object in a big project), it’s
probably better to just put the onus on the developer. Now, if we had a
nice incremental linker…but that’s another thread.
It is quite common for two generic, global scope objects to refer to each
other.
So then, are we saying, it’s not a bug it’s a feature?
“Kris Warkentin” <> kewarken@qnx.com> > wrote in message
news:ani155$85q$> 1@nntp.qnx.com> …
Yes it is. That shouldn’t come up very often however and, if it does,
it’s
usually a sign that something needs to be redesigned.
\
Just a reminder that the Watcom-style resolution of forward references that
Bill wants can still be achieved by use of the -( and -) options to group
libraries on the link line. Mutliple-pass resolution will be performed on
all libraries within the group. Just don’t forget the closing -)!
We don’t find that this adds anything substantial to the link time for our
projects. YMMV.
Also, speaking of link lines don’t forget the standard trick that -langc++
is required at link time if you want exceptions to work.
I think it’s more of an optimization. Consider all the information that
the
linker would have to hold in memory if it were going to try to resolve
forward references. Your only other option would be to make the linker do
multiple passes but, considering that linking is often the longest stage
(especially if you’re only recompiling 1 object in a big project), it’s
probably better to just put the onus on the developer. Now, if we had a
nice incremental linker…but that’s another thread.
cheers,
Kris
“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > wrote in message
news:ani71a$mk2$> 1@inn.qnx.com> …
Not necessarily. Especially with class libraries.
It is quite common for two generic, global scope objects to refer to
each
other.
So then, are we saying, it’s not a bug it’s a feature?
“Kris Warkentin” <> kewarken@qnx.com> > wrote in message
news:ani155$85q$> 1@nntp.qnx.com> …
Yes it is. That shouldn’t come up very often however and, if it does,
it’s
usually a sign that something needs to be redesigned.
Just a reminder that the Watcom-style resolution of forward references
that
Bill wants can still be achieved by use of the -( and -) options to
group
libraries on the link line. Mutliple-pass resolution will be performed on
all libraries within the group. Just don’t forget the closing -)!
We don’t find that this adds anything substantial to the link time for our
projects. YMMV.
Also, speaking of link lines don’t forget the standard trick that -langc++
is required at link time if you want exceptions to work.
Rob Rutherford
“Kris Warkentin” <> kewarken@qnx.com> > wrote in message
news:ani7vk$g9p$> 1@nntp.qnx.com> …
I think it’s more of an optimization. Consider all the information that
the
linker would have to hold in memory if it were going to try to resolve
forward references. Your only other option would be to make the linker
do
multiple passes but, considering that linking is often the longest stage
(especially if you’re only recompiling 1 object in a big project), it’s
probably better to just put the onus on the developer. Now, if we had a
nice incremental linker…but that’s another thread.
cheers,
Kris
“Bill Caroselli (Q-TPS)” <> QTPS@EarthLink.net> > wrote in message
news:ani71a$mk2$> 1@inn.qnx.com> …
Not necessarily. Especially with class libraries.
It is quite common for two generic, global scope objects to refer to
each
other.
So then, are we saying, it’s not a bug it’s a feature?
“Kris Warkentin” <> kewarken@qnx.com> > wrote in message
news:ani155$85q$> 1@nntp.qnx.com> …
Yes it is. That shouldn’t come up very often however and, if it
does,
it’s
usually a sign that something needs to be redesigned.
Just a reminder that the Watcom-style resolution of forward references
that
Bill wants can still be achieved by use of the -( and -) options to
group
libraries on the link line. Mutliple-pass resolution will be performed on
all libraries within the group. Just don’t forget the closing -)!
Just a reminder that the Watcom-style resolution of forward references
that
Bill wants can still be achieved by use of the -( and -) options to
group
libraries on the link line. Mutliple-pass resolution will be performed on
all libraries within the group. Just don’t forget the closing -)!
Well, you learn something new every day… Thanks Rob.
Don’t thank me, thank Colin (Burgess). What little I know about the arcane
world of ld, objdump. ELF (and friends) has been gleaned almost entirely
from Colin’s posts here.