cvs commit: src/lib/libc/gen fts-compat.c fts-compat.h

[Daniel Eischen]

On Fri, 24 Aug 2007, M. Warner Losh wrote:

> There's much resistance to building everything that the build system
> might be used being build static.  It adds too much time and
> complexity to the build system, the opponents say.

So install libc and use LD_LIBRARY_PATH so the build use it
instead of /lib/libc.so.

> : If you are going to remove the interim versioned symbols, that's
> : OK with me, but what are you going to do for the people that miss the
> : transistion period (after the interim symbols are removed)?  Shouldn't
> : the build system work regardless?  If I understand correctly, I  think
> : the more general problem is that the install tools are dependent on
> : working with new libraries.
>
> Should?  Yes.  However, it never has.  There has always been the
> possibility that an incompatible change to libc would take out the
> build tools.  People have been good enough to not change base ABIs to
> prevent this from happening, for the most part.

Install the old libc and let the build tools use it...

> : > If there is some actual harm here, it hasn't been clearly articulated
> : > and needs to be if that's the case.  I'm certainly open to this
> : > possibility.
> :
> : It should be easy to say FBSD_1.0 is RELEASE_7.0, FBBSD_1.1 is RELEASE_7.1,
> : etc.  The versioned symbol namespace is mostly to aid the release
> : engineers.  If you start to have FBSD_1.2, FBSD_1.3,  and FBSD_1.4
> : are interim versions and FBSD_1.5 is release 7.1, that isn't good.
>
> But FBSD_0.9 could be used, no?

Or FBSD_0.hack I suppose too ;-)

> : Again, I highly doubt you would have Sun or even Linux have interim
> : versions that are made public.   If you want to have interim versions
> : and then remove them at a later point before a release, that is a
> : different story, but it doesn't solve the problem for someone missing
> : the transition period, whereas a more general solution would.
>
> I was thinking of leaving it in, undocumented, for the release.

Please don't do that.

> And having a robust build system still doesn't solve the ports problem
> I alluded to.  All of them would still need to be rebuilt.

Yes, but this is -current and we've always dealt with it.  After the
first release with symbol versioning, it shouldn't matter anyways unless
you change the ABI of the same thing more than once in a version def.
Consider:

 	FBSD_1.0 {
 	global:
 		...
 		fts_open;
 		fts_read;
 		fts_children;
 		...
 	local:
 		*;
 	};

After 7.0 release (with FBSD_1.0 as the version), you decide to change
the ABI for fts_open:

 	FBSD_1.0 {
 	global:
 		...
 		fts_open;
 		fts_read;
 		fts_children;
 		...
 	};

 	FBSD_1.1 {
 	global:
 		fts_open;
 	local:
 		*;
 	} FBSD_1.0;

Now you decide to change the ABI for fts_read:

         FBSD_1.0 {
         global:
                 fts_open;
                 fts_read;
                 fts_children;
                 ...
         };

         FBSD_1.1 {
         global:
 		fts_open;
 		fts_read;
 	local
 		*;
 	} FBSD_1.0;

You can change the ABI as many times as you want without adding a
new version definition, as long as you don't change the _same_ ABI.
If you change the same ABI more than once, then yes, you have to
rebuild all your ports and perhaps deal with build problems.

The fts change should either deal with the upgrade problems or
wait until after release when it won't be a problem.

-- 
DE