Re: cvs commit: src/include ctype.h src/lib/libcrypt Makefile src/lib/libskey Makefile src/lib/libutil Makefile

[Joerg Sonnenberger <joerg@xxxxxxxxxxxxxxxxx>]

On Tue, Jun 28, 2005 at 09:47:55AM -0700, Matthew Dillon wrote:
> 
> :..
> :>   possible with older programs.
> :
> :Please back this out, it is just incorrect and can result in random segfaults.
> :It doesn't handle e.g. errno which is used by libskey and possible other changes
> :still planned.
> :
> :Joerg
> 
>     errno could be an issue, but making the libraries call the ctype
>     functions rather then use the macros is not going to cause random 
>     segfaults and, frankly, I would far prefer to have the compatibility
>     then to have them use the macros.

Well, hacking around different libc versions is just asking for trouble IMO.
I'm not sure if rtld bails out on TLS mismatches, that's why I said it can
result in random segfaults. This commit increases the chance of having
broken linkage.

This won't work much longer, as I want to make the libc linkage explicit
for shared libraries too, only thing I still struggle with is profiling
/ debugging support. How much support for debugging with shared libc do
we want? My idea was to install the profiling versions and maybe debugging
versions to /usr/lib/prof (/usr/lib/debug) and teach the GCC frontend to
provide rpath entries of -R/usr/lib/prof -R/usr/lib when linking with -pg,
-R/usr/lib otherwise. This would retire ldconfig for a pkgsrc world too,
which is IMO a nice thing.

>     The real problem here is the PAM libraries.  There appears to be just
>     one set of PAM libraries and that doesn't work when we have a mix
>     of pre-library-upgrade and post-library-upgrade binaries that use them.
>     We need to find a solution for PAM that allows both types of binaries
>     to reside in the system at the same time.

It's the same problem we have with the i18n support. I still think the best
idea is to isolate the compatibility code under /compat/freebsd4.
Each directory under /compat/freebsd4 should have an entry (.compat_replace :-))
which decides whether it hides the "real" directory, so that e.g.
/compat/freebsd4/usr/lib hides the "real" /usr/lib, but /etc is still visible
by both. We can do that now based on the ELF tagging.

Joerg