Ready for test coreutils-5.2.0-1 [again]
Nicholas Wourms
nwourms@netscape.net
Sun Mar 14 20:40:00 GMT 2004
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
More information about the Cygwin-apps
mailing list