GNOME Bugzilla – Bug 704290
make install failed
Last modified: 2015-02-07 16:50:25 UTC
I reported a bug with make install. After running with the debug options, I got more details. There are two glib-2.0 installations, in the old installation, /usr/inlcude/glib-2.0 glib-unix.h and gobject/glib-types.h does not even exists I installed the newer version 2.36.3 in /usr/local/ For some reason, the configure picked up the old installation /usr/lib64/pkgconfig/glib-2.0.pc prefix=/usr exec_prefix=/usr libdir=/usr/lib64 includedir=/usr/include glib_genmarshal=glib-genmarshal gobject_query=gobject-query glib_mkenums=glib-mkenums Name: GLib Description: C Utility Library Version: 2.22.5 Libs: -L${libdir} -lglib-2.0 Libs.private: Cflags: -I${includedir}/glib-2.0 -I${libdir}/glib-2.0/include It is a matter of letting the package know the new location Not sure this can be achieve by a make command line variable or not. I am not an expert in the autoconfig area. Help is greatly appreciate.
After adding symbolic link in the old include directory /usr/include/glib-2.0 to the new include directory /usr/local/glib-2.0 The package passed the missing header file stage, then was choking in another place. This may have something to do with the wrong header directory in the first place. It should be a small adjustment to the configure script somewhere. I am not very good at playing with the autoconf scripts. Reading makefiles... Updating goal targets.... File `install-am' does not exist. File `all-am' does not exist. Prerequisite `stamp-h1' is newer than target `config.h'. Must remake target `config.h'. make[2]: Entering directory `/d1/zhouke/download/failedgobj/gobject-introspection-1.37.4' Successfully remade target file `config.h'. Prerequisite `g-ir-scanner' is newer than target `GLib-2.0.gir'. Must remake target `GLib-2.0.gir'. GISCAN GLib-2.0.gir /usr/local/include/glib-2.0/gobject/glib-types.h:275: syntax error, unexpected identifier in 'GLIB_AVAILABLE_IN_ALL' at 'GLIB_AVAILABLE_IN_ALL' /usr/local/include/glib-2.0/gobject/glib-types.h:277: syntax error, unexpected identifier in 'GLIB_AVAILABLE_IN_ALL' at 'GLIB_AVAILABLE_IN_ALL' /usr/local/include/glib-2.0/gobject/glib-types.h:279: syntax error, unexpected identifier in 'GLIB_AVAILABLE_IN_ALL' at 'GLIB_AVAILABLE_IN_ALL' /usr/local/include/glib-2.0/gobject/glib-types.h:281: syntax error, unexpected identifier in 'GLIB_AVAILABLE_IN_ALL' at 'GLIB_AVAILABLE_IN_ALL'
*** Bug 704280 has been marked as a duplicate of this bug. ***
*** Bug 704283 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > For some reason, the configure picked up the old installation > /usr/lib64/pkgconfig/glib-2.0.pc The reason might be your PKG_CONFIG_PATH. Not a valid bug here but a problem with your own linking setup (system library being picked up, but system library is too old). Closing as INVALID. Feel free to ask for support on the mailing list.
It does not appear to be a problem of the pkg-config echo $PKG_CONFIG_PATH /usr/local/lib/pkgconfig:/usr/local/lib64/pkgconfig I feeling is that the configure.ac or automake file may needs a slight adjustments. Many other packages similar to this had no problem finding the right glib on my system. I say several other people suffering from the same disease. At this point, the problem has been at the compilation stage. It also new to me that, the compilation stage is at the installation stage not at the make stage. We should be only experiencing problems moving the half-made objects into the final destination directories in the target system. I was able to pass the make stage (which should have found the right paths to the include directories), but now it is not finding them in the 'make install' stage. Anyway, thanks for the feedback. Kemin
Hmm. I'll tentatively reopen, but this really sounds like stuff to ask on a mailing list first.
After disabling the pkg config route to the old system: /usr/include$ sudo mv glib-2.0/ glib-2.0_xxx /usr/lib64/pkgconfig]$ sudo mv glib-2.0.pc glib-2.0.pc_xxx sudo make --debug install I am still getting the following error: This program built for x86_64-redhat-linux-gnu Reading makefiles... Updating goal targets.... File `install-am' does not exist. File `all-am' does not exist. Prerequisite `stamp-h1' is newer than target `config.h'. Must remake target `config.h'. make[2]: Entering directory `/d1/zhouke/download/failedgobj/gobject-introspection-1.37.4' Successfully remade target file `config.h'. File `/glib-2.0/include/glibconfig.h' does not exist. Must remake target `/glib-2.0/include/glibconfig.h'. make[2]: *** No rule to make target `/glib-2.0/include/glibconfig.h', needed by `GLib-2.0.gir'. Stop. make[2]: Leaving directory `/d1/zhouke/download/failedgobj/gobject-introspection-1.37.4'
As an validation that pkgconfig was not used: I put the soft link in the old place. If this was used it will trick the package to use the new path etc: /usr/lib64/pkgconfig]$ sudo ln -s /usr/local/lib/pkgconfig/glib-2.0.pc glib-2.0.pc make[2]: Entering directory `/d1/zhouke/download/failedgobj/gobject-introspection-1.37.4' Successfully remade target file `config.h'. File `/usr/include/glib-2.0/gio/*.h' does not exist. Must remake target `/usr/include/glib-2.0/gio/*.h'. make[2]: *** No rule to make target `/usr/include/glib-2.0/gio/*.h', needed by `Gio-2.0.gir'. Stop. If someone can tell me how is the glib-2.0 was located, I could solve this problem. Kemin
In the configuration stage The following macro was fine: PKG_CHECK_MODULES(GLIB, [glib-2.0 >= 2.36.0]) I installed glib 2.36.3 in /usr/local/, but in the make install stage, this variable was changed to something else /usr/ for glib. So it could be automake problem.
(In reply to comment #7) > I am still getting the following error: Did you run "make clean"? The steps are hard to reproduce if they are not well structured.
Yes. I did make clean. I also remove the directory and regenerate the directory from tar -xf I looked did some checking of the make file. The glib-2.0 directory was correctly set in the make file, but somehow it was switched to a different one during make install. At this point I could not figure out why. The autoconf tool generated make files are so difficult to read.
Could you attach the generated config.log and Makefile from the ./configure run you describe in comment 9? I'm afraid without at least those it's impossible to diagnose the problem.
(In reply to comment #12) > Could you attach the generated config.log and Makefile from > the ./configure run you describe in comment 9? > > I'm afraid without at least those it's impossible to diagnose > the problem. Hi Kemin, I am closing this bug report as no updated information has been provided. Please feel free to reopen this bug if you can provide the information that was asked for in a previous comment.
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]