Re: Gnulib and pspdev
Bruno Haible wrote: Hello Sylvain, The build is based on a slightly modified gcc cross-compiler for mipsel, and a minimal libc on top off of newlib (ftp://sources.redhat.com/pub/newlib/) - check 'psptoolchain' and 'pspsdk' at http://svn.ps2dev.org/listing.php?repname=psppath=%2Ftrunk%2F . ... Can you tell me general guidelines to properly deal with these compilation errors? Or is pspdev out of the scope of gnulib? gnulib's support is targeted at the systems which are in wide use and which are normally kept as-is for a couple of years. In your case, or similarly in for bugs in the Haiku kernel or in FreeMiNT or similar projects which are being actively developed, it's just as easy for the developers of that system to fix the bug or add the missing function than it is for gnulib to provide a workaround. The workarounds that are put into gnulib are there to stay. Every additional AC_CHECK_FUNCS or AC_CHECK_HEADERS invocation will slow down the configure process of a couple of packages a bit. - using pathconf when HAVE_PATHCONF isn't defined: Well, you see from gnulib/doc/posix-functions/pathconf.texi that all Unix platforms have this function. pathconf is a little different: while it is available on all Unix-based system, mingw still lacks it. mingw is useful enough that I'm willing to impose the overhead of the single function-existence test. Besides, the same and backupfile modules already test for it, so any project already using one of those will incur no penalty at all.
Re: Gnulib and pspdev
Hi, - Including system's strings.h while it isn't available: gnulib/doc/posix-headers/strings.texi tells you that all platforms have this header file. And I see that MinGW's just include 'string.h'. Good enough :) - missing libc functions: - fchdir.c references 'dup' and 'dup2' which are not present dup and dup2 are very basic. They are present in all portability targets of gnulib. - getcwd references 'rewinddir' which isn't present Likewise, all platforms have opendir and rewinddir. Thanks. I was not sure whether that was common or not in an embedded system. What bothers me though is that the functions aren't used (since the program runs without) yet are still required at compile time, but I guess it would require some work to split the .o's even more. I mean, it's normal in the open-source world that specialized projects use modified source code. In the free software world too :) -- Sylvain
Re: Gnulib and pspdev
Sylvain Beucler wrote: ... - getcwd references 'rewinddir' which isn't present Likewise, all platforms have opendir and rewinddir. Thanks. I was not sure whether that was common or not in an embedded system. What bothers me though is that the functions aren't used (since the program runs without) yet are still required at compile time, but I guess it would require some work to split the .o's even more. s/runs/runs -- as far as you've seen --/ ? At least in the save-cwd module (used e.g., via openat), getcwd is not used in the common case, but under unusual circumstances, fall-back code does use it.
Re: Gnulib and pspdev
Sylvain Beucler wrote: What bothers me though is that the functions aren't used (since the program runs without) yet are still required at compile time Regarding dup and dup2 this is normal: fchdir.c overrides them without calling rpl_dup and rpl_dup2 itself. This code assumes that dup and dup2 exist. dup() is as basic as open(), you know, and it's a one-liner to provide a stub for it. Bruno
Re: Request: srand48/ drand48
On Sun, Mar 22, 2009 at 10:48:51PM +0100, Jim Meyering wrote: Stefan Bienert wrote: I need a fallback implementation of srand48 and drand48 for my GPL project to compile with mingw32 for a certain operating system. Is there a chance that this can be put into a near-by-future revision of Gnulib? Richard Jones worked on precisely that, back in October: http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/15494 I'm not sure what the status is now. Last I looked I was still trying to get Red Hat to sign the appropriate documents so I could contribute code to the FSF. (Even though we have a blanket agreement with the FSF ...) It's all a bit messed up. Rich. -- Richard Jones, Emerging Technologies, Red Hat http://et.redhat.com/~rjones virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://et.redhat.com/~rjones/virt-df/
Re: Request: srand48/ drand48
Richard W.M. Jones wrote: On Sun, Mar 22, 2009 at 10:48:51PM +0100, Jim Meyering wrote: Stefan Bienert wrote: I need a fallback implementation of srand48 and drand48 for my GPL project to compile with mingw32 for a certain operating system. Is there a chance that this can be put into a near-by-future revision of Gnulib? Richard Jones worked on precisely that, back in October: http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/15494 I'm not sure what the status is now. Last I looked I was still trying to get Red Hat to sign the appropriate documents so I could contribute code to the FSF. (Even though we have a blanket agreement with the FSF ...) It's all a bit messed up. Hi Rich, Are you sure you need that? Did you see this? http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/16682/focus=16693 -- Date: Fri, 20 Feb 2009 18:34:01 -0600 Message-Id: 200902210034.n1l0y1z02...@f7.net From: k...@freefriends.org (Karl Berry) ... Well, I'm not from the FSF, but I can confirm it anyway, since that is exactly what I just asked the copyright-clerk :). As long as the work was done as an employee rather than on your own time, RH's global assignment covers you and no separate papers are necessary.
Re: close vs socket vs getline
Bruno Haible br...@clisp.org writes: Some ideas: 1) Should the sockets.m4 module unconditionally add LIBSOCKET to LDADD? 2) Should the gnulib-tool generated Makefile.am add LIBSOCKET to LDADD? No, LDADD has an effect on all executables. I don't want to link all my programs against -lws2_32 just because one of them uses sockets. No, I don't want to add LIBSOCKET to the link dependencies of the 'close' and 'fclose' either. It would also have the effect that all or nearly my programs would link against -lws2_32. Dynamic loading of ws2_32,dll is not the solution either; it would still have the effect of loading an extra library in programs that don't need it. Right. Is there any other options? I propose to move the sockets related part of close() into the 'sockets' module, and connect the close() code with the sockets related code at runtime rather than at compile time. Like this (tested on mingw). Nice idea! It adds some complexity, but it makes the other code easier to understand once you have understood close-hook. I have tested it, and it seems to work for me on mingw and normal x86, and solves the problem. Please push it. /Simon
Re: ls -v is still inconsistent
On Saturday 21 March 2009 00:03:30 Kamil Dudka wrote:
On Friday 20 of March 2009 22:25:30 Bob Proulx wrote:
The '~' is often used in package version numbers. It sorts before the
version without it. For example the rule[1] for generating a stable
backport from the latest unstable version in Debian is: ``Append
~bpo${debian_release}+${build_int} to the version number,
e.g. 1.2.3-4 now becomes 1.2.3-4~bpo50+1, or for native packages,
1.2.3 becomes 1.2.3~bpo50+1.'' (In this way the newer package,
when available, will upgrade and replace the backport.)
Thanks for insight!
Is that a version separator or part of the version number? I am not
going to language lawyer it but will simply point out a common use of
it related to this.
example_1.2.3-4~bpo40+1_all.deb
example_1.2.3-4~bpo50+1_all.deb
example_1.2.3-4~bpo50+2_all.deb
example_1.2.3-4_all.deb
In this example the regex matches only .deb as the file suffix. The
current filevercmp implementation works here as well as the patched one.
Bob
[1] http://www.backports.org/dokuwiki/doku.php?id=contribute
I'll look at it deeper next week and check if the new regex works in all
cases.
The Debian's backport suffix ~bpo${debian_release}+${build_int} seems to
be safe in the context of this patch. Thanks to the '+' it can be never
matched as a file suffix.
Kamil
Re: Gnulib and pspdev
s/runs/runs -- as far as you've seen --/ ? At least in the save-cwd module (used e.g., via openat), getcwd is not used in the common case, but under unusual circumstances, fall-back code does use it. I'd say runs - Bruno explained that 'dup' and 'dup2' are used in auxiliary replacements from fchdir.c, and 'rewinddir' is only used in a chroot+Linux corner case which won't happen on PSP (getcwd still works in the general case). dup() is as basic as open(), you know, and it's a one-liner to provide a stub for it. AFAICS pspdev provides 'fnctl' with 'F_DUPFD' support, so indeed that should be easy to add (in 'newlib/libc/sys/psp/libcglue.c'), thanks for the tip! -- Sylvain
Re: ls -v is still inconsistent
Kamil Dudka wrote:
Kamil Dudka wrote:
I'll look at it deeper next week and check if the new regex works in all
cases.
The Debian's backport suffix ~bpo${debian_release}+${build_int} seems to
be safe in the context of this patch. Thanks to the '+' it can be never
matched as a file suffix.
Thanks for taking this into consideration!
Bob
Re: Serial number formats
Hello Bruno, * Bruno Haible wrote on Mon, Mar 23, 2009 at 12:28:51AM CET: http://lists.gnu.org/archive/html/bug-gnulib/2005-02/msg0.html Without consensus on the question whether interoperability is desirable, it is moot to discuss the format. As I read the archives, at some point in the past interoperability was deemed desirable by several members of this list Yes, I see: the whole area is crufty, and I think they can be removed. said Paul Eggert. There is a certain point to that. Today, the situation is as follows, I would say: - Interoperability between 'aclocal' and gnulib provided *.m4 files is present, of course. What we are discussing is whether the 'aclocal' feature to choose one or the other .m4 file based on the version number should be applied to gnulib provided *.m4 files. Yes. - In gnulib, the macro files, source code files, and Makefile.am snippets form a unit. If gnulib provides an stdint.in.h that comes with stdint.m4 version 22, but 'aclocal' then chooses to prefer stdint.m4 version 23, breakage in stdint.in.h is possible or even likely. It does not matter from where this newer version of stdint.m4 came from. All that matters is that gnulib-tool did not install it. Agreed. - Similarly, the gettext provided *.m4 files (gettext.m4, intl.m4, etc.) form a unit. If one of them is replaced with a newer version and the others are not, again, breakage is possible or likely. Agreed. gnulib-tool and autopoint are already racing each other, which makes the `AUTOPOINT=true autoreconf -vi' necessary sometimes. Not adding another car into the race might just be a good thing. For this reason, I don't think it's desirable that gnulib and gettext provided macro files use the # serial nn syntax that activates the 'aclocal' comparison feature. OK. Colin started this thread by pointing out a particular situation (multiple copies of gettext.m4 in a source tree), and I hope I convinced him that this situation is better avoided. A patch proposal for 'autopoint' to help avoiding this situation is currently under consideration. OK. Alexandre wrote on 2005-02-01: 3. # FILENAME serial NNN 4. # FILENAME serial NNN (PACKAGES) 5. # FILENAME serial STRING (PACKAGES) ... the latter 3 schemes will be ignored by aclocal. At least in the current implementation. This is fine as is, IMO. Great. We're all in violent agreement once all the information is on the table. :-) It is a bit sad to see that the aclocal scheme hasn't caught on more, but it's certainly not a perfect solution for macros which require being synchronized with other, non-macro files. Cheers, Ralf
Re: Request: srand48/ drand48
My project is GPL. Is it really legally OK to copy LGPL code verbatim into my project? Yes, because the LGPL has a specific provision allowing upgrading to the GPL.
Building strtoull on HP-UX 10.20 requires stdint which is not included
With latest gnulib on HP-UX 10.20: $ ./gnulib-tool --create-testdir --dir=t strtoull $ cd t $ ./configure ... $ gmake ... source='dummy.c' object='dummy.o' libtool=no \ DEPDIR=.deps depmode=hp /bin/sh ../build-aux/depcomp \ cc -Ae -DHAVE_CONFIG_H -I. -I.. -g -c dummy.c source='strtoull.c' object='strtoull.o' libtool=no \ DEPDIR=.deps depmode=hp /bin/sh ../build-aux/depcomp \ cc -Ae -DHAVE_CONFIG_H -I. -I.. -g -c strtoull.c cpp: stdlib.h, line 52: error 4036: Can't open include file 'stdint.h'. gmake[4]: *** [strtoull.o] Error 1 -- albert chin (ch...@thewrittenword.com)
