bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Gnulib and pspdev


From: Bruno Haible
Subject: Re: Gnulib and pspdev
Date: Mon, 23 Mar 2009 00:55:01 +0100
User-agent: KMail/1.9.9

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=psp&path=%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.

> - 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.

> - 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.

In summary, these are functions and headers that are so widespread that
  - If your goal is to compile a couple more programs for your system, you
    will add them, sooner or later.
  - If your goal is to provide just a system for one single application,
    you can very well live with a modified copy of gnulib, or use the
    gnulib option --local-dir to account for your local changes.

I mean, it's normal in the open-source world that specialized projects use
modified source code. We try to merge forks that contain important features
or that are gaining widespread distribution. The state of your project, as
you have described it, makes it sound that a source-code-modified gnulib is
currently the better option.

Bruno




reply via email to

[Prev in Thread] Current Thread [Next in Thread]