Re: Ready for test coreutils-5.2.0-1 [again]

[Nicholas Wourms <nwourms at netscape dot net>]

cgf wrote:

> On Sun, Mar 14, 2004 at 01:18:20PM -0500, Nicholas Wourms wrote:
>
> Joshua Daniel Franklin already mentioned this on Friday.  It's the
> standard way of dealing with this.

Yeah, I guess that one slipped through the cracks at my end.

> This would seem to imply that all of these mknetrel fragments are
> dealing with that awful lack of POSIX compliance, which is not the case.

Nope, I was implying that there were other config tidbits which might be 
of some use...  As for ash's lack of compliance, it does cause trouble 
at times when some program/script expects it to be smarter then it 
really is.

Just so I don't get some flame about my not doing anything, I will note 
that I'm attempting to refresh our sources with the latest from NetBSD, 
merging in any relevant local changes.  The primary reason is so I can 
support and submit the IEEE SUSv3 wordexp() function, which requires 
/bin/sh possess certain features.  I've tried to use bash, but it was 
terribly slow and had some unexpected behavior, despite claims at posix 
compliance.  Anyhow, my patch will include some of the FreeBSD mods to 
ash, which were designed with the explicit support of wordexp() in mind. 
 Despite the FUD floating around, I'm still getting a binary 
significantly faster and smaller then bash (initial observations between 
my sh and the current sh indicate very little difference in postinstall 
time when running the automatic infodir script).  I would like to 
discuss this more with Corinna when I have it working solid.  I hope 
then to make my argument on why we should go with a more robust /bin/sh.

> No, actually it's not.  1) Adding -L/usr/lib makes no sense.  2)
> -lbinmode doesn't work, anyway.  I added the libraries a while ago
> thinking it would make things easier but since nothing in the main
> program references anything in libbinmode.a, nothing from libbinmode.a
> is loaded.  You do need to either take that fact into account or just
> load binmode.o.

I'm sorry, I saw that the libraries were being installed and thought 
they worked.  Stupid me for thinking that they actually got linked in, I 
should have been more vigilant and verified it.  I'm glad you clarified 
this.  Of course, I think I can come up with a quick hack to ld which 
would override the default symbol checking logic for 
lib{auto,bin,text}mode.a.  I'm not disputing that we can currently do 
it, but it is rather cumbersome and is a small PITA to get working with 
libtool (which barfs on linking non-libtool objectfiles).  Of course, 
one must still take your original fact into account when building 
non-libtool static libs, since obviously ar won't suck it in.

Cheers,
Nicholas