Re: problems statically linking thirdparty libs and dynamically linking glibc

[Christopher Baus]

>> 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.