Board index » kylix » Force linking against NPTL or LinuxThreads+Floating Stacks?

Force linking against NPTL or LinuxThreads+Floating Stacks?


2006-04-21 06:19:30 AM
kylix2
Does anyone know how to force a Kylix app to use NPTL or
LinuxThreads+Floating Stacks if they're available? Under Fedora 4 all
three are available, but the app still uses the oldest LinuxThreads
libraries. Under Fedora 5 it started using the NPTL libraries, but I'm
not sure what changed or how to make it consistently work under other
distros. Setting LD_ASSUME_KERNEL to 2.4.1 or 2.4.20 doesn't seem to
make any difference.
Thanks,
Craig Peterson
Scooter Software
 
 

Re:Force linking against NPTL or LinuxThreads+Floating Stacks?

On 2006-04-20, Craig Peterson <"craig no scootersoftware spam com">wrote:
Quote
Does anyone know how to force a Kylix app to use NPTL or
LinuxThreads+Floating Stacks if they're available? Under Fedora 4 all
three are available, but the app still uses the oldest LinuxThreads
libraries. Under Fedora 5 it started using the NPTL libraries, but I'm
not sure what changed or how to make it consistently work under other
distros. Setting LD_ASSUME_KERNEL to 2.4.1 or 2.4.20 doesn't seem to
make any difference.
I'm not 100% sure, but couldn't it be that 2.6 kernels don't support the old
model anymore, and the old linuxthread lib APIs are built on top of NTPL,
which adds the NTPL dependancy?
 

Re:Force linking against NPTL or LinuxThreads+Floating Stacks?

Quote
On 2006-04-20, Craig Peterson <"craig no scootersoftware spam com">wrote:
>Does anyone know how to force a Kylix app to use NPTL or
>LinuxThreads+Floating Stacks if they're available? Under Fedora 4 all
>three are available, but the app still uses the oldest LinuxThreads
>libraries. Under Fedora 5 it started using the NPTL libraries, but I'm
>not sure what changed or how to make it consistently work under other
>distros. Setting LD_ASSUME_KERNEL to 2.4.1 or 2.4.20 doesn't seem to
>make any difference.

I'm not 100% sure, but couldn't it be that 2.6 kernels don't support the old
model anymore, and the old linuxthread lib APIs are built on top of NTPL,
which adds the NTPL dependancy?
No, this is not the case.
Simon
 

{smallsort}

Re:Force linking against NPTL or LinuxThreads+Floating Stacks?

Quote
Does anyone know how to force a Kylix app to use NPTL or
LinuxThreads+Floating Stacks if they're available? Under Fedora 4 all
three are available, but the app still uses the oldest LinuxThreads
libraries. Under Fedora 5 it started using the NPTL libraries, but I'm
not sure what changed or how to make it consistently work under other
distros. Setting LD_ASSUME_KERNEL to 2.4.1 or 2.4.20 doesn't seem to
make any difference.
I once stated investigation to find this out myself, but can't remember
the outcome out of my head. I *think* depending on the distro, the lib
path used was chosen based on GLIBC/ELF version tags in the binary (which
Kylix doesn't create).
I'm personally also very interested in this, so if you get any findings
before I do (on my to-do-list for a LONG time already), please post here.
Simon
 

Re:Force linking against NPTL or LinuxThreads+Floating Stacks?

Quote
Does anyone know how to force a Kylix app to use NPTL or
LinuxThreads+Floating Stacks if they're available? Under Fedora 4 all
three are available, but the app still uses the oldest LinuxThreads
libraries. Under Fedora 5 it started using the NPTL libraries, but I'm
not sure what changed or how to make it consistently work under other
distros. Setting LD_ASSUME_KERNEL to 2.4.1 or 2.4.20 doesn't seem to
make any difference.
Here are a few (old) findings by myself:
- On Red Hat (and some Red-Hat-Like) distro, NPTL is around for quite
some time. Red Hat even backported it to the 2.4 kernel. By default
binaries running on Red Hat will get a NPTL-aware libc. If you do not
wish to have NPTL, you may use LD_ASSUME_KERNEL to force a different
ABI version. Kylix compiled ELFs don't have any ABI version tag, still
Red Hat uses NPTL for them. All is fine here.
The same seems to be the case with Suse (but not really tested from my
side)
- On Debian 3.1, things work completely different. To get NPTL, you have
to install an additional libc package, which will be installed to
/lib/tls/. Also you need to run a 2.6 kernel. ld will now examine the
ELF, and depending on $unknown, it will choose to either use the NPTL
libc from /lib/tls, or the regular one from /lib. As I understood it,
to find out which to use, it checks out the ABI-Tag of the ELF (some
section called .note.ABI-tag) to decide that. Kylix compiled
applications don't have that, and Debian 3.1 will use the regular
/lib/ libc. So: On Debian 3.1 Kylix applications work fine, but they
don't use NPTL. And up to now I have not found a way to force the
usage of NPTL. Sad, but at least Kylix applications work.
---
I remember we fixed this issue for FPC/CrossFPC. It probably simply
is the missing ABI tag in Kylix executables.
Simon
_______________________________________________
CrossFPC mailing list
XXXX@XXXXX.COM
mailman.rockz.org/cgi-bin/listinfo/crossfpc
 

Re:Force linking against NPTL or LinuxThreads+Floating Stacks?

Hi Simon,
Thanks, I found your previous post of this in Google, and it gave me
hope, but unfortunately it appears you're incorrect.
Quote
- On Red Hat (and some Red-Hat-Like) distro, NPTL is around for quite
some time. Red Hat even backported it to the 2.4 kernel. By default
binaries running on Red Hat will get a NPTL-aware libc.
My testing here does not reflect this.
Fedora Core 4 has the following directory structure:
/lib =>NPTL
/lib/obsolete/linuxthreads =>2.2 LinuxThreads
/lib/obsolete/linuxthreads/i686 =>2.4 LinuxThreads + Floating Stacks
And Kylix-compiled applications always link against the 2.2 LinuxThreads.
Fedora Core 5 only has the NPTL libraries in /lib, and doesn't have
either /lib/obsolete version. So as far as I can tell, Marco is correct
that the only reason it works correctly under Fedora Core 5 is that they
dropped the backwards compatibility libs.
I checked the above using both LDD and using confstr. If you can
confirm different behavior I'm very interested in hearing it.
The test against confstr was just this:
program whatthread;
uses
libc;
const
_CS_GNU_LIBPTHREAD_VERSION = 3;
var
len: size_t;
s: string;
begin
len := confstr(_CS_GNU_LIBPTHREAD_VERSION, nil, 0);
if len>0 then
begin
SetLength(S, len - 1);
confstr(_CS_GNU_LIBPTHREAD_VERSION, PChar(S), len);
WriteLn(S);
end
else
WriteLn('confstr failed');
end;
On Fedora Core 4 and an old install of Lindows it returns "LinuxThreads
0.10", and under Fedora Core 5 it returns "NPTL 2.4".
Quote
- On Debian 3.1, things work completely different. To get NPTL, you
have to install an additional libc package, which will be installed
to /lib/tls/. Also you need to run a 2.6 kernel. ld will now examine
the ELF, and depending on $unknown, it will choose to either use the
NPTL libc from /lib/tls, or the regular one from /lib.
I tested a Debian install over the weekend saw the same behavior as
you're describing, which is consistent with my Fedora 4 observations.
Quote
As I understood it, to find out which to use, it checks out the ABI-Tag of
the ELF (some section called .note.ABI-tag) to decide that. Kylix
compiled applications don't have that, and Debian 3.1 will use the
regular /lib/ libc.
I don't think it's the .note.ABI-tag that's affecting things. I used
objcopy to remove it from a copy of bash (objcopy
--remove-section=.note.ABI-tag bash) and it still linked to the newer
libraries.
It's possible it has to do with the .gnu.version_r section, but I can't
check that since every time I remove it from bash using objcopy LDD
gives the error "unsupported version 0 of verneed record". Removing the
.gnu.version (no _r) doesn't seem to affect things.
Quote
I remember we fixed this issue for FPC/CrossFPC. It probably simply
is the missing ABI tag in Kylix executables.
Yep, I just checked and it is working in FPC, and removing the
.note.ABI-tag doesn't affect things there either. On Fedora Core 4 the
code above returns NPTL 2.3.5. Do you know who I did the work so I
could ask them about it?
Does FPC support CLX yet? Has CrossFPC been released? Any idea how
stable the TThread support is?
Thanks,
Craig
 

Re:Force linking against NPTL or LinuxThreads+Floating Stacks?

On 2006-04-24, Craig Peterson <"craig no scootersoftware spam com">wrote:
Quote
>I remember we fixed this issue for FPC/CrossFPC. It probably simply
>is the missing ABI tag in Kylix executables.
(wasn't this the bi-arch situatation?)
Quote
Yep, I just checked and it is working in FPC, and removing the
.note.ABI-tag doesn't affect things there either. On Fedora Core 4 the
code above returns NPTL 2.3.5. Do you know who I did the work so I
could ask them about it?
Afaik there wasn't done anything special. We have had some problems using
SA_RESTORER lately.
Quote
Does FPC support CLX yet? Has CrossFPC been released? Any idea how
stable the TThread support is?
No (not even a design criterium, since not free enough). That's why CrossFPC
exists ,
Not that I know ,
Enough to get Indy running fine. There are threading issues in the bugtracker
tho.
 

Re:Force linking against NPTL or LinuxThreads+Floating Stacks?

Marco van de Voort wrote:
Quote
Afaik there wasn't done anything special. We have had some problems using
SA_RESTORER lately.
Ok, thanks. I suspect it's the missing .gnu.version_r section that's
causing the problem.
Quote
No (not even a design criterium, since not free enough). That's why CrossFPC
exists ,
I'm confused. Isn't CrossFPC just FPC set up as a cross compiler and
the Delphi IDE plug-ins? I thought I saw Simon say he'd worked with the
FPC folks to get it compiling CLX (supporting resources on Linux, etc).
Is CrossFPC a fork?
Craig
 

Re:Force linking against NPTL or LinuxThreads+Floating Stacks?

On 2006-04-25, Craig Peterson <"craig no scootersoftware spam com">wrote:
Quote
Marco van de Voort wrote:
>Afaik there wasn't done anything special. We have had some problems using
>SA_RESTORER lately.

Ok, thanks. I suspect it's the missing .gnu.version_r section that's
causing the problem.

>No (not even a design criterium, since not free enough). That's why CrossFPC
>exists ,

I'm confused. Isn't CrossFPC just FPC set up as a cross compiler and
the Delphi IDE plug-ins?
Yes and no. The major difference is exactly that, CLX. FPC doesn't come with
such libs, and recompiling the Kylix supplied CLX and some other units
completes the CrossFPC picture.
Quote
I thought I saw Simon say he'd worked with the
FPC folks to get it compiling CLX (supporting resources on Linux, etc).
Correct. However the FPC interest is to help Kylix folks and Simon in
particular, and to stresstest FPC, combined with the fixes form Simonflowing
The Kylix route however is not a design goal of FPC.
FPC exists longer on Linux than Kylix existed. Almost longer than 32-bit
Delphi existed even. This shows, e.g. unit "libc" in "real" FPC is just a
Kylix compat library, and as an unportable unit not recommended for new
development.
Quote
Is CrossFPC a fork?
No, the FPC core participates and is interested, though Simon is clearly
the main motor. It is just more comparable with a specialised distribution
than with the main focus of the distro.