strtoull.patch and intptr_t.patch don't apply to file 4.24 any more. Please check. Additional remark/request: please when adding patches for an OS, add its name to the patch name, such that it is easy to see what patch belongs to what (which is quite handy during syncing).
for the moment we'll have to remove the interix keyword from file 4.24, since they made getopt unconditional, but interix doesn't have built-in getopt (argl). maybe we'd need a interix-getop package or something like that. i have a working getopt implementation which could be taken for this....
It's masked globally in prefix, since it also has screwed up something with autotool for at least Solaris. With this added I think it was a good move to mask it globally, as I don't trust it at all any more. re: getopt, also debianutils has this jumbo-getopt(long?) patch that haubi added. Maybe we can indeed make a getopt-compat package or something for platforms that require it.
@getopt-compat: IIRC this would solve problems with some other things on interix too, so +1 for such a package :)
<thoughts> Unsure if this should be a separate real-library. Such GNU-addons/completions usually should be shipped with the package, originally coming from http://www.gnu.org/software/gnulib/ But eventually we could create a standalone gnulib library, and have gcc by specs-patching link it in along libc. Eventually, existent configure-checks in correctly gnulib-using packages should detect gnulib parts already existing and omit the package-private gnulib parts. </thoughts>
Newest gnulib usually has bugs fixed, in particular for the weirder platforms. On the other hand, why can't we do something like this gnuconfig thing in Portage? It updates config.guess from the latest installed in the system to avoid packages not detecting a chost somehow. We could just detect gnulib and update, and maybe even via a variable inject the sources somehow?
To do some update is one thing, and could be possible indeed. But to introduce a new gnulib part (like getopt for file-4.24) won't be that easy IMO, as it very likely is more than just simply append some lines to the end of configure.ac and Makefile.am. But eventually we could do like for the interix' _ALL_SOURCE thing, to keep it out of gcc-specs: Add LDFLAGS=-lgnulib in profile.bashrc on non-linux, and filter-ldflags for now-broken packages.
Ok, then gnulib is a separate (compiled) package containing the dynamic and static gnulib library, I presume? Problem I have with doing it always is that you get needless references. I already noticed when using -strip_dead_dylibs (sort of --as-needed on Darwin) that you do not get any libgcc_s.dylib references any more; in other words, most of our Darwin/Solaris systems depend on this lib (with the occasional breakage now and then) while they don't need it at all. Adding another such lib just makes it more fragile IMO. Considering the number of packages we talk about here that need it (really minimal IMO) don't we better do it in the ebuilds (and depend on gnulib there) instead?
(In reply to comment #7) > Ok, then gnulib is a separate (compiled) package containing the dynamic and > static gnulib library, I presume? Static only, but built with PIC-flags, so it can be linked into a shared library. > > Problem I have with doing it always is that you get needless references. I > already noticed when using -strip_dead_dylibs (sort of --as-needed on Darwin) > that you do not get any libgcc_s.dylib references any more; in other words, > most of our Darwin/Solaris systems depend on this lib (with the occasional > breakage now and then) while they don't need it at all. Adding another such > lib just makes it more fragile IMO. When linking static libs, AFAICT the linker punts any unneeded object file. > Considering the number of packages we talk about here that need it (really > minimal IMO) don't we better do it in the ebuilds (and depend on gnulib there) > instead? Same here as for -D_ALL_SOURCE: For only a few packages do it in the ebuilds. Question is if we provide a real gnulib _library_, or just the gnulib _sources_ to be copied over to ${S} by the ebuild. OTOH: Having it as shared library would help bugfixes.
-D_ALL_SOURCE is like an epidemic virus spread over the ebuild tree, so I don't agree with that statement.
I meant: If -D_ALL_SOURCE were for a few packages only, do it in the ebuilds. If necessary for too many packages, do it in a generic way.
Ok. You already remarked that trying to plug in the sources is a tedious job, so I guess we're stuck with having a gnulib.a (static library) that we link to in case an application needs GNU-specific functions. (Means we could slim down debianutils again, ideally...) I think the gnulib functions are sufficiently small to be linked in, instead of dynamically loaded --- in fact existing applications that use gnulib do the same. We might want to make sure packages that distribute gnulib, use our (latest) gnulib.a, which perhaps can be done with a simple copy, such that make just doesn't regenerate, but that's of later concern. Does that make sense?
(In reply to comment #11) > Ok. You already remarked that trying to plug in the sources is a tedious job, > so I guess we're stuck with having a gnulib.a (static library) that we link to > in case an application needs GNU-specific functions. (Means we could slim down > debianutils again, ideally...) I think the gnulib functions are sufficiently > small to be linked in, instead of dynamically loaded --- in fact existing > applications that use gnulib do the same. Exactly, yes. > We might want to make sure packages > that distribute gnulib, use our (latest) gnulib.a, which perhaps can be done > with a simple copy, such that make just doesn't regenerate, but that's of > later concern. To make it clear for everyone: it's not to copy over libgnulib.a, but specific parts (source files) of gnulib, which are conditionally compiled along the package if necessary - detected by configure. So we would need to update both the configure-checks _and_ the source files - maybe spread all over that package (I've just sometimes seen a gnulib/ subdir). Additionally, who says that they use unmodified/unrenamed copies of gnulib parts? But: above configure-results depend on what gets linked in by default. Iff -lgnulib is used always, shouldn't the gnulib-configure checks detect that nothing from local gnulib/ (however its name is) is needed? If that works, it'd be much easier than heuristically update gnulib sources. Could this be worth a try?
I just put file-4.25 in the tree. You may want to look at that too?
in file-5.00 they seem to see the need for an internal getopt replacement, and thats why it works again ;)
