From: Jeffrey Hutzelman <[EMAIL PROTECTED]> replied:
...
> On Wednesday, March 14, 2007 12:20:20 AM -0700 Russ Allbery
> <[EMAIL PROTECTED]> wrote:
>
> > Marcus Watts <[EMAIL PROTECTED]> writes:
> >> Russ Allbery <[EMAIL PROTECTED]> writes:
> >
> >>> Er, linking against pthread is very attractive to me on Linux. What am
> >>> I missing?
> >
> >> Depending on the version of linux (& glibc) you're more or less likely
> >> to get a "different process" per thread, which affects things like
> >> "kill", "wait", and "ps".
> >
> > So it's just low-level weirdness along those lines? That doesn't really
> > bother me. (And hm, doesn't the new threading model not expose things
> > that way any more, or am I confused?)
>
> You are not confused; it hasn't worked that way in some time, and even when
> it did, it wasn't as bad as all that. Yes, multiple threads were
> separately visible in ps (and still are, if you use the correct switch),
> but waiting and signal delivery actually worked they way they should.
This depends on 2.4 vs. 2.6, glibc, & to some extent various patches
and distribution weirdness. Jeff apparently enjoys the luxury of
not having to worry about these older environments. I, on the other hand,
am still cursed with having to deal with these older environments,
for a variety of reasons not relevant here. Fortunately for Russ,
I'm probably not representative of the typical user.
>
>
> >> Also, it's not as true as all that even on amd64. On amd64, even by
> >> default, non-pic executables link dynamically against pic shared
> >> libraries. Non-pic executables can also be statically linked against
> >> pic objects. What breaks is linking non-pic code into shared libraries
> >> and objects.
> >
> > Right, sorry. Yes, there are cases that are even more restrictive, but
> > that's the common one and the one that I'm the most concerned with, since
> > it's directly relevant to both Perl modules and PAM modules.
> >
> >> Indeed, on most machines, non-pic code in shared libraries is frowned
> >> upon, and amd64 is merely enforcing a very common policy. It happens to
> >> work with i386/gnu, and that's the real anomaly here.
>
...
> I wouldn't describe this as "enforcing a policy". It's not just a policy;
> there are technical reasons why putting non-PIC code in shared objects
> doesn't work. Those just happen not to apply on some platforms, and I
> think we all agree that there has been much bad practice as a result of
> x86-linux being one of them.
Whether shared objects need to be relocatable is itself a "policy
choice", made mostly by the OS developers. It's quite possible to have
a shared object that is not relocatable, and ld.so or its logical
equivalent is in fact often built that way for many architectures. It
can be highly efficient because non-relocatable shared libraries
will need far fewer runtime fixups. On the other hand, it makes system
updates much harder to do, and it limits flexibility, which is why it's
not a popular choice today.
All this is just details. The interesting thing here is that
on some environments (such as solaris, linux), it is common
and install both pic code in shared libraries, and non-pic code
in static libraries. On other environments, it's shared & non-shared
libraries have a library pathname problem and nearly all code, shared
or not, is pic. One of the strengths of openafs is that it
works in a heterogeneous community - and that means openafs
needs to make some effort to fit in with choices such as this.
...
-Marcus
_______________________________________________
OpenAFS-devel mailing list
OpenAFS-devel@openafs.org
https://lists.openafs.org/mailman/listinfo/openafs-devel
