[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
libgcc_s.so. 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
that
> 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
shared.
> 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
static
> and one shared. I can't seem to see any way to do that with g++'s
linker
> switches.
>
> I think it is a bug that when you pass valid switches to g++ it barfs
with
> 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.