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 172212 - Cannot create gnm-marshalers.lo, with a historic make
Cannot create gnm-marshalers.lo, with a historic make
Status: RESOLVED FIXED
Product: Gnumeric
Classification: Applications
Component: Compilation
git master
Other All
: Normal normal
: ---
Assigned To: Stepan Kasal
Stepan Kasal
Depends on:
Blocks:
 
 
Reported: 2005-03-31 10:05 UTC by Stepan Kasal
Modified: 2005-03-31 12:40 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Stepan Kasal 2005-03-31 10:05:53 UTC 
The build fails in subdir src/, complaining that there is no rule to create
gnm-marshalers.lo .
This problem doesn't appear with GNU make.

(Actually, I have never experienced this bug, I just noticed a problem in
src/Makefile.am.  See below for an explanation.)
Comment 1 Stepan Kasal 2005-03-31 11:06:25 UTC 
To get gnm-marshalers.lo, make has to chain two implicit rules:
.list.c:
.c.lo:

Though POSIX make implementations are supposed to be able to do it, some
historic make implementations have problems here.
Comment 2 Stepan Kasal 2005-03-31 11:09:27 UTC 
A general solution to this problem is to write another implicit rule for
.list.lo:

But we don't have to bother with this.  It is sufficient to add the file
gnm-marshalers.c to the special hint variable BUILT_SOURCES.  (This hack also
fixes bug #172211.)
Comment 3 Stepan Kasal 2005-03-31 12:40:19 UTC 
I have found another solution:

If you mention gnm-marshalers.c as a prerequisite of a rule, like this:

gnm-marshalers-dummy: gnm-marshalers.c

then the historic make is able to chain the two implicit rules.

I have verified this on OSF1 V4.0, which is my "historic make".  I hope it'll
help with other historic implementations, too.

So this seems to be the most elegant solution to both this bug and bug #172211.