[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: problems statically linking thirdparty libs and dynamically linking
Re: problems statically linking thirdparty libs and dynamically linking glibc
Thu, 15 Jul 2004 09:26:45 -0700 (PDT)
>> 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
> 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
> 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.