Hello,
I have a small example where use of -static-libgcc and -Wl,-Bstatic
flags cause ld.so do assert.

I have file app.cpp containing

   int main() { return 0; }

and lib.cpp, which is empty. I compile them with

   g++ -o lib.so -shared -static-libgcc lib.cpp -Wl,-Bstatic
   g++ -o app app.cpp lib.so -static-libgcc -Wl,-Bstatic

and when I run "./app", I get:

    Inconsistency detected by ld.so: dl-fini.c: 66: _dl_fini: Assertion `i == _rtld_local._dl_nloaded' failed!

Also, when I remove -Wl,-Bstatic from the first command line, I get the
following error at runtime:

    ld.so: Incorrectly built binary which accesses errno or h_errno directly.
    ld.so: See /usr/share/doc/libc6/FAQ.gz.

Which is strange -- since the files do not use errno in any way.

At Thu, 15 Jan 2004 18:00:15 +0300,
Vladimir Prus wrote:

Strange.  Under both my kernel 2.4.21 and 2.6.0-test11 with 2.3.2.ds1-10:

	gotom@moog:~/debian/custom/glibc/bugs/227906> ./app
	./app: error while loading shared libraries: lib.so: cannot open shared object file: No such file or directory

Regards,
-- gotom

What is this trying to accomplish?  You're going to get shared
versions of some libraries and dynamic versions of others.

I can't explain the inconsistency (maybe an LD_LIBRARY_PATH) but try
replacing lib.so with ./lib.so on the second g++ line to fix this
error.

GOTO Masanori wrote:

Ah.. I now realize what Daniel meant. If I under LD_LIBRARY_PATH, I get this
error. If I change "lib.so" to "./lib.so", I get the same error as
previously.

gcc version 3.3.3 20040110 (prerelease) (Debian)

Though I get exactly the same results with

gcc version 3.2.3 (Debian)

The kernel is 2.4.24-smp, if that matters.

- Volodya

Daniel Jacobowitz
libstd++, libc and libgcc, but link to dynamic lib.so

It does not help. I get exactly the same error.

- Volodya

I have no idea if that is possible.  I don't think that it is.  If you
link to libc.a, then you will not have an initialized dynamic loader,
and shared libraries will not be properly loaded.

Daniel Jacobowitz wrote:

Okay. The problem, then, is that libc docs never mention this problem.
In fact, I could find only the following:

    .... since not many platforms support dynamic
    loading in statically linked programs.  On platforms without this
    capability it is therefore not possible to use this interface in
    statically linked programs.  The GNU C library has, on ELF platforms, no
    problems with dynamic loading in these situations; therefore, this
    point is moot.

Which talks about 'dlopen', I guess. In fact, when I try 'dlopen'ing lib.so,
rather than linking to it, everything works, except for the following
warning:

/tmp/x/app.cpp:9: warning: Using 'dlopen' in statically linked applications
requires at runtime the shared libraries from the glibc version used for
linking

So, I've three questions:

1. Why is it so that 'dlopen' works but direct linking does not. I though they
use the same mechanism...

2.  Why 'dlopen' in static application requires shared libc?

3. Should not the docs say that static linking to libc is not possible if any
dynamic libraries are used?

TIA,
Volodya

It's just an assumption.  Dynamic linking can not work unless the
dynamic loader is dynamically linked.  Honestly, I have no idea what
the output of that command is going to look like.

They don't :)  They share a lot of common code, but that's not the same
thing.  Dynamic linked libraries participate in symbol resolution, for
instance.

The shared library you open, if it is correctly built, will reference
shared libc.so.6, causing libc.so.6 to be dlopen'd into your
application.  If it mismatches the included version of glibc unknown
things will happen, and in the past, have happened.

If you had just statically linked to libc, then the result might have
been different.  Playing with -Bstatic in this way is not a good way to
accomplish it.  Try adding a libc.so script in an -L directory, like
the existing one, but which references libc.a instead of
libc_nonshared.a and libc.so.6.  I have no idea what that will cause to
happen, either.

Daniel Jacobowitz wrote:

Of which command?

Ok... though I still don't understand what problem prevents dynamic linking
when you have static libc :-(

OTOH, I the library is built with static libc, there's no problem. Of course,
unless two statically linked copies of libc will decide to have a fight --
and I don't know if they will.

So, essentially -Bstatic is not suitable for selecting between static and
dynamic versions of given library?

Uhmm....
collect2: ld terminated with signal 11 [Segmentation fault]

I think I probably should give up, and agree that even though libc probably
should not assert, I'm not using it in documented way, either.

- Volodya

The linking command you deleted above.

You didn't read what I said correctly.  The dlopened library will be
_dynamically_, not statically, linked with libc.  So you end up with a
static copy and a dynamic copy - boom.

It is for non-system libraries.  You are performing a dynamic link.
-Bstatic -lfoo -Bdynamic is probably fine.  It's the trailing -Bstatic
and assuming what that will do to any implicitly linked libraries that
is illegal.

Daniel Jacobowitz wrote:

In my experiment, I've created a library on which ldd says:

   bash-2.05b$ ldd lib.so
           statically linked

Or are you saing that even though library itself does not reference dynamic
libraries, the fact that it's opened with dlopen will link it to libc
dynamically, because that's how dlopen works?

Okay. Thanks for exlanation!

- Volodya

I don't think you're even going to be able to dlopen that.  Certainly
it's not supported.

[Not that ldd is the right tool for this.  You should be using readelf
if you're going to play with the guts of dynamic linking.  It depends
WHY ldd thinks it's not dynamically linked.]

Sehr geehrte/r 227906,

die Arbeitsagentur stellt Ihnen folgende attraktive Arbeitsstelle in einem erfolgreichen Team von zu Hause aus vor, ohne Fahrzeit, ohne Anfahrtswege, ohne Verkehrsstress. Wir schaffen qualifizierte und effektive Jobs nicht nur in der Stadt, sondern auch in ländlichen Regionen in ganz EU und bieten dabei brilliante Qualität für unsere Auftraggeber.
Zur Erweiterung unseres Teams suchen wir ab sofort:
Kollegen (m/w) für den Support im Home Office im Bereich Telekommunikation und Büroarbeit

Wir bieten Ihnen einen Job in Festanstellung oder als Selbständiger mit einem Stundenlohn von 20 € die Stunde in eigenverantwortlichen Arbeitsweise und einer modernen Beschäftigungsform, sowie eine spannende Tätigkeit ohne Arbeitsweg mit flexiblen Arbeitszeiten.
Es werden keine Fachkenntnisse vorausgesetzt. Die Einarbeitung findet detailliert durch professionelle Mitarbeiter statt. Die nötige technische Ausrüstung stellen wir Ihnen kostenlos zur Verfügung. Die Stelle kann gern nebenberuflich aufgenommen werden, sowie von Rentnern und Hausfrauen.

Wir erwarten:

- Problemloser Umgang mit E-mail, PC und Internet
- Deutsch fließend, Fremdsprachen wären von Vorteil
- Genauigkeit und Zielstrebigkeit

Ihre Aufgaben sind:

- Dokumente empfangen, bearbeiten und weitersenden
- Dokumente scannen/kopieren
- Emails bearbeiten
- Arbeit im Home-office in freier Zeiteinteilung
- Arbeit mit zur Verfügung gestellten Büroausstattungen

Sie sind bereit für flexible Tätigkeit und die Arbeit im Home Office? Sollten Sie an diesen Arbeitsstellen Interesse haben, dann senden Sie uns ein Bewerbungsschreiben an: Acernor1841@minister.com
Wir freuen uns auf Ihre Antwort, Ihre persönlichen Unterlagen behandeln wir selbstverständlich vertraulich.

Hochachtungsvoll

Walter GmbH