Statically linking a library problem...

[oxblood]

Hi,

I'm trying to statically link a library I creat with
'ar rcs mylib.a .o files....'

If I link only the .o files with my .c file, I get no
compile error and the program runs fine. But if I link
it with the library I have archived, I get undefined
reference to the methods I'm calling from those .o files.
The mylib.a does contain all the .o files and I've
tried to link it with (or without) -L and even done
ranlib mylib.a but still no good. All files are under
a single directory.

I was wondering if someone could shed some light here.

Thanks

 

[Ben Pfaff]

I'm trying to statically link a library I creat with
'ar rcs mylib.a .o files....'

Your question is outside the domain of comp.lang.c, which discusses
only the standard C programming language, including the standard C
library. This is a remarkably narrow topic compared to what many
people expect.

For your convenience, the list below contains topics that are not
on-topic for comp.lang.c, and suggests newsgroups for you to explore
if you have questions about these topics. Please do observe proper
netiquette before posting to any of these newsgroups. In particular,
you should read the group's charter and FAQ, if any (FAQs are
available from www.faqs.org and other sources). If those fail to
answer your question then you should browse through at least two weeks
of recent articles to make sure that your question has not already
been answered.

* OS-specific questions, such as how to clear the screen,
access the network, list the files in a directory, or read
"piped" output from a subprocess. These questions should be
directed to OS-specific newsgroups, such as
comp.os.ms-windows.programmer.misc, comp.unix.programmer, or
comp.os.linux.development.apps.

* Compiler-specific questions, such as installation issues and
locations of header files. Ask about these in
compiler-specific newsgroups, such as gnu.gcc.help or
comp.os.ms-windows.programmer.misc. Questions about writing
compilers are appropriate in comp.compilers.

* Processor-specific questions, such as questions about
assembly and machine code. x86 questions are appropriate in
comp.lang.asm.x86, embedded system processor questions may
be appropriate in comp.arch.embedded.

* ABI-specific questions, such as how to interface assembly
code to C. These questions are both processor- and
OS-specific and should typically be asked in OS-specific
newsgroups.

* Algorithms, except questions about C implementations of
algorithms. "How do I implement algorithm X in C?" is not a
question about a C implementation of an algorithm, it is a
request for source code. Newsgroups comp.programming and
comp.theory may be appropriate.

* Making C interoperate with other languages. C has no
facilities for such interoperation. These questions should
be directed to system- or compiler-specific newsgroups. C++
has features for interoperating with C, so consider
comp.lang.c++ for such questions.

* The C standard, as opposed to standard C. Questions about
the C standard are best asked in comp.std.c.

* C++. Please do not post or cross-post questions about C++
to comp.lang.c. Ask C++ questions in C++ newsgroups, such
as comp.lang.c++ or comp.lang.c++.moderated.

* Test posts. Please test in a newsgroup meant for testing,
such as alt.test.

news.groups.questions is a good place to ask about the appropriate
newsgroup for a given topic.

 

[Tom St Denis]

Hi,

I'm trying to statically link a library I creat with
'ar rcs mylib.a .o files....'

If I link only the .o files with my .c file, I get no
compile error and the program runs fine. But if I link
it with the library I have archived, I get undefined
reference to the methods I'm calling from those .o files.
The mylib.a does contain all the .o files and I've
tried to link it with (or without) -L and even done
ranlib mylib.a but still no good. All files are under
a single directory.

Depends on the order ... e.g.

gcc mylib.a somefile.o -o test

is different than

gcc somefile.o mylib.a -o test

GCC will resolve depends left-to-right. E.g. Linked into "test" will be
all of the modules from mylib.a needed at that point (in the case of the
former no depends exist yet where in the latter they may).

Internally on most platforms the link would actually be

crt0.o $(YOURSTUFF) libc.a


crt0.o for instance depends on main() which should be located in one of
YOURSTUFF object files. YOURSTUFF is probably dependent on libc.a, etc,
etc..

Tom