Re: make error: dir-ops.cc:61: error: ‘ strerror ’ is not a member of ‘ gnulib ’

[John W. Eaton]

On 27-Oct-2010, Alexandru Cabuz wrote:

| Turns out the error does not appear on debian testing, only on stable. This
| means that there are some libraries which are old on stable, but that the
| testing version is sufficiently recent that the error does not appear.
| 
| However, I don't know which library that is, so I can update it and move on...
| and I can't just upgrade the whole system to testing, that would create way
| more problems than it would solve...
| 
| I have tried attaching the gzipped config.log file, but it's too big and the
| list refuses it. However, I can send it on direct email to anyone who might
| want to take a look at it...
| 
| libtool: compile:  g++ -DHAVE_CONFIG_H -I. -I.. -I../libgnu -I../libgnu -I../
| libcruft/misc -g -O2 -DHAVE_CONFIG_H -Wall -W -Wshadow -Wold-style-cast
| -Wformat -g -O2 -pthread -g -O2 -MT liboctave_la-dir-ops.lo -MD -MP -MF .deps/
| liboctave_la-dir-ops.Tpo -c dir-ops.cc  -fPIC -DPIC -o .libs/
| liboctave_la-dir-ops.o
| 
| dir-ops.cc: In member function ‘bool dir_entry::open(const std::string&)’:
| dir-ops.cc:61: error: ‘strerror’ is not a member of ‘gnulib’
| make[3]: *** [liboctave_la-dir-ops.lo] Erreur 1
| make[3]: quittant le répertoire « /home/cabuz/comsolwork/BLASlibsetc/
| octave-3.3.53/liboctave »
| 
| make[2]: *** [all] Erreur 2
| make[2]: quittant le répertoire « /home/cabuz/comsolwork/BLASlibsetc/
| octave-3.3.53/liboctave »
| 
| make[1]: *** [all-recursive] Erreur 1
| make[1]: quittant le répertoire « /home/cabuz/comsolwork/BLASlibsetc/
| octave-3.3.53 »
| make: *** [all] Erreur 2

What version of GCC do you have?  I think the problem is probably the
same as reported here:

  https://www-old.cae.wisc.edu/pipermail/help-octave/2010-June/020186.html

(and at several other times).  The GCC bug is described here:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38000

If this is the cause of the problem you are having, then the fix is to
either upgrade GCC or manually fix your header files that incorrectly
use #include_next (those that are changed by the patch shown in the
GCC bug report):

  http://gcc.gnu.org/viewcvs?view=revision&revision=143194

jwe