[EMAIL PROTECTED] (Karl Berry) writes: > Is it a problem in practice, ie, what are these non-Unix linkers?
I've run into it on IBM mainframe platforms. You can run into it even with GCC, if you use -fno-common. Googling a bit reveals that libtool 1.5 uses -fno-common on Mac OS X (why, I don't know; see <http://www.tug.org/pipermail/tex-k/2003-June/000723.html>). > This will require revamping pretty much everybody that uses > program_name, but I think it's worth the pain. What do others > think? > > Sounds like an uphill battle to me. The hill shouldn't be steep. The gnulib tradition is to not worry about backward-compatibility much, at least for trivial improvements like this. The idea is that people can import new gnulib source code at their convenience. I realize that at time goes on the hill will become steeper, but I'd rather keep it as flat as possible if I can. [EMAIL PROTECTED] (James Youngman) writes: > I would prefer an arrangement which results in a compilation or link > failure if the user (i.e. software maintainer) fails to initialise > things properly. Perhaps we could change progname.h so that 'program_name' is a function that returns the program name, instead of being a global variable. That should catch mishaps at link-time, if not before. _______________________________________________ bug-gnulib mailing list bug-gnulib@gnu.org http://lists.gnu.org/mailman/listinfo/bug-gnulib
