After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 164678 - Build failure in examples/input directory on RHEL 3 (gcc 3.2.3) with GARNOME (2.9.4)
Build failure in examples/input directory on RHEL 3 (gcc 3.2.3) with GARNOME ...
Status: RESOLVED FIXED
Product: gtkmm
Classification: Bindings
Component: build
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gtkmm-forge
gtkmm-forge
Depends on:
Blocks:
 
 
Reported: 2005-01-20 09:57 UTC by Vincent
Modified: 2005-01-25 09:20 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
gtkmm configure log (16.27 KB, text/plain)
2005-01-20 09:58 UTC, Vincent
Details
gtkmm compilation log (758.27 KB, text/plain)
2005-01-20 09:59 UTC, Vincent
Details
gtkmm compilation log (10.74 KB, application/x-compressed-tar)
2005-01-20 10:01 UTC, Vincent
Details

Description Vincent 2005-01-20 09:57:30 UTC
Hello,

I'm currently GARNOME'ing GNOME 2.9.4 and build fails in the examples/input
directory of gtkmm. 

The error is the following :
[...]
main.cc: In function `int main(int, char**)':
main.cc:43: `access' undeclared (first use this function)
main.cc:43: (Each undeclared identifier is reported only once for each function
   it appears in.)
main.cc:68: `unlink' undeclared (first use this function)
make[5]: *** [main.o] Error 1
[...]

Attached are the complete configure and compilation logs.

This seems related to an error with the <iostream> header not found as the
missing functions should be in it (AFAIK).
Note that this failure did not happen in 2.8.2 as the input/ directory is newly
added in 2.9.4.

Workaround is to remove the incriminating directory (rm -rf input) and its
reference in the Makefile (in the SUBDIRS variable).

My workstation is RHEL (Redhat entreprise v3). gcc specs are :
gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-20)
My original post on the GARNOME list :
http://mail.gnome.org/archives/garnome-list/2005-January/msg00058.html

Thanks for your help,

Vincent
Comment 1 Vincent 2005-01-20 09:58:07 UTC
Created attachment 36284 [details]
gtkmm configure log
Comment 2 Vincent 2005-01-20 09:59:02 UTC
Created attachment 36285 [details]
gtkmm compilation log

Complete gtkmm compilation up to failure point
Comment 3 Vincent 2005-01-20 10:01:13 UTC
Created attachment 36286 [details]
gtkmm compilation log

Complete gtkmm compilation log up to failure point. Compressed as original
weights 700K+
Comment 4 Vincent 2005-01-20 10:06:29 UTC
Sorry, typo. 
This is in the example/book/input directory (and not example/input).
Comment 5 Murray Cumming 2005-01-20 14:44:36 UTC
Could you please trying adding
#include <unistd.h>
at the top, if it is not already there.
Comment 6 Vincent 2005-01-20 15:33:33 UTC
Hello Murray,

The fix you propose solves the problem (compilation resumed successfully). Perfect! 

Thanks.
Comment 7 Murray Cumming 2005-01-20 15:42:19 UTC
OK. That fix was already made yesterday for the SUN Forte compiler. 

Thanks for the strange data point.
Comment 8 Chris Vine 2005-01-22 13:09:36 UTC
You also need to include sys/types.h and sys/stat.h (for mkfifo()) - see main.cc
in the iochannel_stream example in glibmm.

As Glib::IOChannel is being used, the open of the fifo should also be blocking
(see also main.cc in the iochannel_stream example).  The author of this example
based it on my non-blocking code example but failed to spot the point when
changing it to use Glib::IOChannel (as well omitting necessary includes).
Comment 9 Murray Cumming 2005-01-23 19:34:29 UTC
> You also need to include sys/types.h and sys/stat.h (for mkfifo())

Not until I hear of an actual compilation error on some platform.

> the open of the fifo should also be blocking

Thanks, but could you provide a (tested) patch, please?
Comment 10 Chris Vine 2005-01-24 20:15:49 UTC
On includes, see 'man 3 mkfifo'.  Why not just do the right (standards
conforming) thing, rather than depend on what the compiler/other headers may or
not include?  Deciding whether to include headers by seeing what error a
particular compiler may spew out is not a sound technique (that approach
probably caused the bug which started this).

On the fifo, the line:
  read_fd = open("testfifo", O_RDONLY | O_NONBLOCK);
needs to be changed to:
  read_fd = open("testfifo", O_RDONLY);

I can send a patch for this if you like (but it would contain a correction of
the headers).  However, I do not have the current CVS version of gtkmm
installed.  (Will you take one off gtkmm-2.5.5?)
Comment 11 Murray Cumming 2005-01-25 09:20:44 UTC
> Why not just do the right (standards conforming) thing,

Because even that can break a build somewhere. They are already in cvs for the
SUN compiler anyway.

I have removed | O_NONBLOCK now too. Thanks.