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 362898 - CVS libgda compilation fails on sqlite provider (no rule for sqlite_specs_create_db.xml)
CVS libgda compilation fails on sqlite provider (no rule for sqlite_specs_cre...
Status: RESOLVED FIXED
Product: libgda
Classification: Other
Component: SQLite provider
1.9.x
Other All
: Normal normal
: ---
Assigned To: malerba
gnome-db Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-10-17 16:27 UTC by Marc-Andre Lureau
Modified: 2006-12-29 15:43 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
switch two lines of the providers/*/Makefile.am (4.29 KB, patch)
2006-10-20 00:26 UTC, Marc-Andre Lureau
none Details | Review

Description Marc-Andre Lureau 2006-10-17 16:27:50 UTC
Please describe the problem:
gcc -shared  .libs/gda-sqlite-ddl.o .libs/gda-sqlite-handler-bin.o .libs/gda-sqlite-provider.o .libs/gda-sqlite-recordset.o .libs/utils.o .libs/libmain.o -Wl,--whole-archive ../../providers/sqlite/sqlite-src/.libs/libsqlite.a -Wl,--no-whole-archive  -Wl,--rpath -Wl,/home/elmarco/cvs/gnome2/libgda/libgda/.libs -Wl,--rpath -Wl,/opt/gnome2/lib -Wl,--rpath -Wl,/opt/gnome2/lib ../../libgda/.libs/libgda-3.so -L/opt/gnome2/lib -L/home/elmarco/cvs/gnome2/libgda/libsql/.libs /opt/gnome2/lib/libgobject-2.0.so /opt/gnome2/lib/libgthread-2.0.so /opt/gnome2/lib/libgmodule-2.0.so -ldl /opt/gnome2/lib/libglib-2.0.so /opt/gnome2/lib/libxslt.so -lz -lm /opt/gnome2/lib/libxml2.so  -pthread -Wl,--export-dynamic -Wl,-soname -Wl,libgda-sqlite.so -o .libs/libgda-sqlite.so
creating libgda-sqlite.la
(cd .libs && rm -f libgda-sqlite.la && ln -s ../libgda-sqlite.la libgda-sqlite.la)
make[3]: *** Pas de règle pour fabriquer la cible « sqlite_specs_create_db.xml », nécessaire pour « all-am ». Arrêt.
make[3]: quittant le répertoire « /home/elmarco/cvs/gnome2/libgda/providers/sqlite »
make[2]: *** [all-recursive] Erreur 1
make[2]: quittant le répertoire « /home/elmarco/cvs/gnome2/libgda/providers/sqlite »
make[1]: *** [all-recursive] Erreur 1
make[1]: quittant le répertoire « /home/elmarco/cvs/gnome2/libgda/providers »
make: *** [all-recursive] Erreur 1
*

Steps to reproduce:
compiled from jhbuild 2.18 environnement

Actual results:


Expected results:


Does this happen every time?
yes

Other information:
Comment 1 Marc-Andre Lureau 2006-10-20 00:25:40 UTC
Vivien,

Actually, this bug seems not to be related to dash, but to GNU make. A step-by-step stripped down version of the generated Makefile has been the only way to track the bug. May be this is finally a shell issue. I don't know.

Anyway, I swapped some line in the Makefile to figure out that just moving up the rule was enough to correct it.

Please find the patch enclosed.
Comment 2 Marc-Andre Lureau 2006-10-20 00:26:46 UTC
Created attachment 75049 [details] [review]
switch two lines of the providers/*/Makefile.am
Comment 3 malerba 2006-10-20 12:39:51 UTC
You mean just adding an empty line before "xml_DATA = $(xml_in_files:.xml.in=.xml)" does the trick? 
Comment 4 Marc-Andre Lureau 2006-10-20 13:00:39 UTC
no, the @INTLTOOL_XML_RULE@ need to be inserted before the xml_DATA line.

Weird, really. 
Comment 5 Marc-Andre Lureau 2006-10-20 13:04:02 UTC
When I cut down the generated Makefile, I noticed that the swap was not necessary (normal). But with the original large Makefile, the swap was needed. That's why I think it's related to GNU Make (something like a "rule limit"...?)  
Comment 6 malerba 2006-10-20 13:15:51 UTC
All right, I understand because the patch you proposed here does not do that, it simply adds an empty line before the "xml_DATA = $(xml_in_files:.xml.in=.xml)" lines.
Comment 7 Marc-Andre Lureau 2006-10-20 13:32:54 UTC
The "diff" view is not helpful in this case. The xml_DATA line is *really*
below the @INTLTOOL_stuff@ after applying the patch (or I am a fool) :)
Comment 8 malerba 2006-10-20 13:37:52 UTC
Ooops, sorry I was a bit quick there, you're not a fool!

Thanks for the patch!

Vivien
Comment 9 Murray Cumming 2006-12-27 17:54:08 UTC
Is this still nececessary? Should it be applied?
Comment 10 Murray Cumming 2006-12-27 17:54:32 UTC
By the way, "cvs diff -up" patches are easier to read.
Comment 11 malerba 2006-12-29 15:43:47 UTC
It's been applied some time ago, I forgot to close the bug at that time. Closing now.