cvs commit: src Makefile.inc1 src/lib/libc Makefile src/lib/libc_r Makefile src/lib/libpthread Makefile pthread.map src/lib/libpthread/thread thr_private.h src/lib/librt Makefile src/lib/libthr Makefile pthread.map src/lib/libthread_db Makefile ...

[Daniel Eischen]

On Thu, 16 Jun 2011, Jilles Tjoelker wrote:

> On Sun, Jun 12, 2011 at 09:38:42PM +0000, Bjoern A. Zeeb wrote:
>> http://svnweb.freebsd.org/base?view=revision&revision=169524
>
>> I figured WITHOUT_SYMVER= hs been useless since 201001.  I am no
>> longer able to do build worlds with WITHOUT_SYMVER= set in src.conf
>> on a system with symbol versioning.
>
>> I'd love someone to fix that and allow us to build libraries without
>> all the historic stuff in them.  If we cannot get it back working our
>> libraries will grow bigger and bigger forever.
>
>> If one is building images for clean-state systems that will never run
>> anything older than the current CURRENT build, there is no need for
>> the extra size.   Contrary to what people think, memory and direct
>> attached storage can still be expensive in some environments.
>
>> Anyone who understands the system can come up with patches to fix this?
>
> I think disabling symver completely is too much: it implies a new
> mutually incompatible set of binaries. What should be done instead is
> allowing to compile out the compatibility functions. This means all
> __sym_compat() directives and all functions referred to by them. A
> simple approach would use a yes/no #ifdef, while a more sophisticated
> approach would allow choosing the oldest version to retain compatibility
> with, for example freebsd7_semctl() in lib/libc/gen/semctl.c would be
> compiled in iff compatibility with FreeBSD 7.x was requested.

I like this approach.  But if you can do that, then is it much
more to remove symbol versioning completely?  I've forgotten.
I know there were some potential problems trying to install
a symver-free world over a symver world.

-- 
DE