This morning I saw that r10664 merged revisions
10495-10497,10551,10554,10556-10559,10663 into the 2.2 fixes branch. I pulled down the changes, recompiled fpc, and ran the tests which were uploaded here: http://bugs.freepascal.org/view.php?id=9089 (here's the direct link to the file:
http://bugs.freepascal.org/file_download.php?file_id=6363&type=bug).

It looks like the INIT section is being called, but I also get an error:

$ ./ptest
INIT
Test
0
Inconsistency detected by ld.so: dl-fini.c: 195: _dl_fini: Assertion `ns != 0 || i == nloaded' failed!

My setup:
Free Pascal Compiler version 2.2.1 [2008/04/14] for i386 Ubuntu Linux 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

-SG

In your source tree, check tests/webtbs/tw9089*.pp (compile tw9089[a- d] and then run "LD_LIBRARY_PATH=. ./tw9089c" and "LD_LIBRARY_PATH=. ./ tw9089d"). That's the test case I distilled from your test programs and which works fine for me. I've googled a bit and found a very long thread about the above assertion at http://lists.debian.org/debian-glibc/2004/01/msg00189.html

The conclusion of that thread appears to be that (in that case) it's caused by linking both to a static and to a dynamic version of libc, causing all sorts of trouble.

My setup: Free Pascal Compiler version 2.2.1 [2008/04/14] for i386 Ubuntu Linux 2.6.22-14-generic #1 SMP Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux

I tested on Linux 2.6.23.15-137.fc8 #1 SMP Sun Feb 10 17:48:34 EST 2008 i686 i686 i386 GNU/Linux

Jonas

tw9089c returns:

INIT
INIT2
Test
0
Inconsistency detected by ld.so: dl-fini.c: 195: _dl_fini: Assertion `ns != 0 || i == nloaded' failed!

When I get home tonight I'll try it on another box to see if it's just something wrong with my configuration.

By the way, thanks a lot, I really appreciate your efforts!

-SG

Okay, so I ran it on a different distribution and it worked fine...

INIT
INIT2
Test
0
FINI2
FINI

No "assertion failed" message or anything of the sort. This second system I tried was:
Linux 2.6.12-23mdk #1 Fri Jul 7 13:15:45 MDT 2006 i686 Intel(R) Core(TM)2 Duo CPU T7250 @ 2.00GHz unknown GNU/Linux

So ... what does that mean?

-SG

The assertion comes from ld.so, which is not a part of the kernel but part of glibc. It means that either their is a bug in the particular glibc/ld.so on the other machine, or at least an incompatibility between how we do things and what that glibc's ld.so expects (although afaik we're not doing anything special).

Jonas

What is the version of glibc on the machine that causes a problem?

Jonas

What is the version of glibc on the machine that causes a problem?

$ /lib/libc.so.6
GNU C Library stable release version 2.6.1, by Roland McGrath et al. Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled by GNU CC version 4.2.1 (Ubuntu 4.2.1-5ubuntu4). Compiled on a Linux >>2.6.15.7<< system on 2007-09-30. Available extensions:
crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al BIND-8.2.3-T5B
For bug reporting instructions, please see:
<http://www.gnu.org/software/libc/bugs.html>.

Thanks,

-SG

I've tested on systems with glibc 2.3.6, 2.5 and 2.7 and all work fine (I don't have access to systems with other glibc versions installed). I therefore think this was just a bug in 2.6.1 (possibly also 2.6), so unless someone analyses the cause of the problem with glibc 2.6.1, I'm not going to spend time on this.

Jonas

Okay, if you've tested it on that many other platforms I'll take your word for it. Thanks again you for your effort!

-SG