[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: problems statically linking thirdparty libs and dynamically linking

From: Christopher Baus
Subject: Re: problems statically linking thirdparty libs and dynamically linking glibc
Date: Thu, 15 Jul 2004 09:26:45 -0700 (PDT)
User-agent: SquirrelMail/1.4.2-1

>> It is not a bug in g++.  The GCC 3.X series introduced a shared  There is no longer a static libgcc.
>> You will not be able to achieve a full static link using GCC unless you
configure/build GCC so that it doesn't use shared libraries.
> Ok maybe I'm missing something here, but I don't want to statically link
the libgcc, just libxml2 and argtable2.  Assume that all the code from
libxml2 and argtable2 where compiled into the executable as .o's, and
> object is linked the shared libgcc, libg++, and lib
> I have compiled libxml2 and argtable2 into static .a files.  I see no
reason while I can't link those statically and link gcc libraries
> But there seems to be no switch in gcc to do that.
> Here's a more general problem.  What if I want to link one library
> and one shared.  I can't seem to see any way to do that with g++'s
> switches.
> I think it is a bug that when you pass valid switches to g++ it barfs
> a really strange error like this.

I'm pretty convinced the problem is with the -static flag.  There isn't
enough granularity.  The odd thing is I know the linker can do what I want
to do.  argtable2 produces both a shared and static library.  If I delete
the shared library, and don't pass static, the linker does exactly what I
want.  If I leave the default configuration, there is no way to link
argtable2.a and the shared system libs.

I guess the solution is to take the shared versions of argtable2 out of
the linker path.  I knew that going in, but I thought I could come up with
something more elegant.  I guess I was wrong.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]