Mon 20 Feb 2012 08:38:10 PM UTC, comment #8:
Can this bug be closed? It is 5 months old and Tatsuro and others have had success building the development branch of Octave on MinGW with running into gnulib fflush problems.
|
Fri 14 Oct 2011 04:55:45 PM UTC, comment #7:
I grepped for gnulib in the mingw tree and didn't find anything. So I possibly do not have any other gnulib than to one installed by octave.
You can find the config.log here in hope that it can help diagnose the problem.
w3.ualg.pt/~jluis/config.log.zip
BTW, I got another error in util.cc line 1298
#if defined (_GNUG_) && !CXX_ISO_COMPLIANT_LIBRARY
std::streambuf *sb = os.rdbuf ();
if (sb)
{
BEGIN_INTERRUPT_IMMEDIATELY_IN_FOREIGN_CODE;
retval = sb->vform (fmt, args); <=== HERE HERE
saying vform is not a member of streambuf. I noticed that this happens under a condition !CXX_ISO_COMPLIANT_LIBRARY (what ever it means).
The solution was similar than on previous cases. That is #ifdefed to use the other branch of the test
char *s = octave_vsnprintf (fmt, args);
if (s)
{
os << s;
retval = strlen (s);
}
and there is goes, happy compiling ... till next problem
|
Fri 14 Oct 2011 04:23:10 PM UTC, comment #6:
Yes, I understand but don't know the answer right now. I'll investigate and come back with what I will find.
Thanks
|
Fri 14 Oct 2011 03:46:38 PM UTC, comment #5:
As I said before, even if your system provides these functions (every system does, I think, provide fflush, fgets, etc.) there may be problems that gnulib fixes.
And in any case, the way gnulib works, the gnulib:: qualifier is used to arrange for either the gnulib replacement function to be called, or for the one provided by the system to be called. So there is no need to remove the gnulib:: qualifier even on systems that have perfectly working versions of these functions.
If there is a bug in the configuration such that the version of gnulib in the source tree is not being found, then I need more information about precisely how that can happen in order to debug and fix it.
Where is the other obsolete copy of gnulib installed on your system? How did Octave's configure script detect it?
|
Fri 14 Oct 2011 03:37:59 PM UTC, comment #4:
Yes, I have a gnulib sub-dir under my octave tree pulled with hg, but is not my fault that building system probably decided to pick up another gnulib version that might have been installed by the mingw installer. Besides, my patch proves that, at least on MingW, ther is no need to use fflush, fgets, etc from gnulib because the 'native' functions work well.
|
Fri 14 Oct 2011 02:56:34 PM UTC, comment #3:
When you ran autogen.sh, you should have picked up a current copy of gnulib sources from the gnulib git archive. The files will be placed in the gnulib subdirectory of the Octave source tree. We assume that you are building with a current version of the gnulib sources, checked out from the gnulib source archive. If you have something older, that is not guaranteed to work.
|
Fri 14 Oct 2011 02:38:20 PM UTC, comment #2:
John,
I also built on Fedora and had no such messages, but I get them with MinGW. On both cases I'm using the dev branch downloaded with hg. If gnulib comes with Octave's dev branch than I have it, otherwise I guess that the one used is that installed by the MinGW installer.
Joaquim
|
Fri 14 Oct 2011 02:20:14 PM UTC, comment #1:
Even if a system provides a function, it might have problems that the gnulib version fixes. So the correct fix is to add the gnulib:: tag to any functions that we call that could be replaced by gnulib.
But I'm surprised that you see these messages. Compiling on my system with the current Octave and gnulib sources, I don't see any messages about any functions not being members of the gnulib namespace, or any messages about gnulib:: tags missing for functions that gnulib provides.
Do you have a current version of gnulib checked out with the Octave sources?
|
Fri 14 Oct 2011 01:57:14 AM UTC, original submission:
Hi,
While trying to build the dev version on MinGW I get several errors like
lo-utils.cc: In function 'std::string octave_fgets(FILE*, bool&)':
> lo-utils.cc:127:11: error: 'fgets' is not a member of 'gnulib'
> lo-utils.cc:127:11: note: suggested alternatives:
> c:\mingw\bin\../lib/gcc/mingw32/4.6.1/../../../../include/stdio.h:354:39: note: 'fgets'
and the same for fflush and others. I solved a couple of these with #ifdefs but this should have been a configure's job.
If mingw provides fgets, fflush, ... it should not try to use those in gnulib.
#if !defined(_MINGW32_) && !defined(_MINGW64_)
gnulib::fflush (stderr);
#else
fflush (stderr);
#endif
|