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 605156 - Error building gir-repository from gnome-shell jhbuild when libgirepository installed from package (openSUSE 11.2)
Error building gir-repository from gnome-shell jhbuild when libgirepository i...
Status: RESOLVED FIXED
Product: gobject-introspection
Classification: Platform
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: gobject-introspection Maintainer(s)
gobject-introspection Maintainer(s)
: 621500 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2009-12-21 18:20 UTC by Sandy Armstrong
Modified: 2015-02-07 16:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
make with error (4.10 KB, text/plain)
2010-04-09 21:14 UTC, Giuseppe Fuggiano
  Details
Move pkg-config calls before --library and --program (976 bytes, patch)
2010-06-25 12:10 UTC, Colin Walters
committed Details | Review
Revert "fix bug#605156 by ordering libtool archives that may pull in system" (2.24 KB, patch)
2010-06-25 18:59 UTC, Colin Walters
committed Details | Review

Description Sandy Armstrong 2009-12-21 18:20:25 UTC
On openSUSE 11.2, seed packages bring in libgirepository, which causes build errors in a gnome-shell jhuild environment:

*** Building gir-repository *** [2/7]
make  
make  all-recursive
make[1]: Entering directory `/home/sandy/gnome-shell/source/gir-repository'
Making all in gir
make[2]: Entering directory `/home/sandy/gnome-shell/source/gir-repository/gir'
/home/sandy/gnome-shell/install/bin/g-ir-scanner -v --namespace Gdk --nsversion=2.0 \
	    --add-include-path=. --add-include-path=. \
             --include=Gio-2.0 \
             --include=cairo-1.0 \
             --include=Pango-1.0 \
	     --include=xlib-2.0 \
             --include=GdkPixbuf-2.0 \
	     --library=gdk-x11-2.0 \
	     --library=libgirepo-Gdk-custom.la \
	     --libtool="/bin/sh ../libtool" \
             --output Gdk-2.0.gir \
             --pkg gobject-2.0 \
             --pkg gio-2.0 \
             --pkg cairo \
             --pkg atk \
             --pkg pango \
             --pkg gdk-x11-2.0 \
             -DGDK_COMPILATION \
	     ./Gdk-custom.c ./Gdk-custom.h \
             `pkg-config --variable=includedir gdk-x11-2.0`/gtk-2.0/gdk/*.h
In file included from <stdin>:37:
/usr/include/gtk-2.0/gdk/gdkx.h:82:28: error: gdkprivate-x11.h: No such file or directory
/usr/include/gtk-2.0/gdk/gdkx.h:83:27: error: gdkscreen-x11.h: No such file or directory
Traceback (most recent call last):
  • File "/home/sandy/gnome-shell/install/bin/g-ir-scanner", line 38 in <module>
    sys.exit(scanner_main(sys.argv))
  • File "/home/sandy/gnome-shell/install/lib/gobject-introspection/giscanner/scannermain.py", line 316 in scanner_main
    namespace = glibtransformer.parse()
  • File "/home/sandy/gnome-shell/install/lib/gobject-introspection/giscanner/glibtransformer.py", line 159 in parse
    self._execute_binary()
  • File "/home/sandy/gnome-shell/install/lib/gobject-introspection/giscanner/glibtransformer.py", line 289 in _execute_binary
    self._read_introspect_dump(out_path)
  • File "/home/sandy/gnome-shell/install/lib/gobject-introspection/giscanner/glibtransformer.py", line 301 in _read_introspect_dump
    self._introspect_type(child)
  • File "/home/sandy/gnome-shell/install/lib/gobject-introspection/giscanner/glibtransformer.py", line 670 in _introspect_type
    self._introspect_object(xmlnode)
  • File "/home/sandy/gnome-shell/install/lib/gobject-introspection/giscanner/glibtransformer.py", line 706 in _introspect_object
    parent_type_names = xmlnode.attrib['parents'].split(',')
KeyError: 'parents'
make[2]: *** [Gdk-2.0.gir] Error 1
make[2]: Leaving directory `/home/sandy/gnome-shell/source/gir-repository/gir'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/sandy/gnome-shell/source/gir-repository'
make: *** [all] Error 2
*** Error during phase build of gir-repository: ########## Error running make   *** [2/7]


After speaking to walters in IRC, he asked me to run this:

[sys] ~/gnome-shell/source/gir-repository (master)
$ jhbuild run strace -f -e open make 2>&1|grep -i girepository
[pid 20113] open("/home/sandy/gnome-shell/install/include/gobject-introspection-1.0/girepository.h", O_RDONLY|O_NOCTTY|O_LARGEFILE) = 5
[pid 20116] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.la", O_RDONLY|O_LARGEFILE) = 4
[pid 20116] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.la", O_RDONLY|O_LARGEFILE) = 4
[pid 20116] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.la", O_RDONLY|O_LARGEFILE) = 4
[pid 20116] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.la", O_RDONLY|O_LARGEFILE) = 4
[pid 20116] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.la", O_RDONLY|O_LARGEFILE) = 4
[pid 20116] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.la", O_RDONLY|O_LARGEFILE) = 4
[pid 20183] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.so", O_RDONLY|O_LARGEFILE) = 5
[pid 20183] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.so", O_RDONLY|O_LARGEFILE) = 6
[pid 20183] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.so", O_RDONLY|O_LARGEFILE) = 6
[pid 20183] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.so", O_RDONLY|O_LARGEFILE) = 6
[pid 20183] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.so", O_RDONLY|O_LARGEFILE) = 6
[pid 20183] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.so", O_RDONLY|O_LARGEFILE) = 6
[pid 20183] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.so", O_RDONLY|O_LARGEFILE) = 6
[pid 20183] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.so", O_RDONLY|O_LARGEFILE) = 6
[pid 20183] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.so", O_RDONLY|O_LARGEFILE) = 6
[pid 20183] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.so", O_RDONLY|O_LARGEFILE) = 6
[pid 20183] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.so", O_RDONLY|O_LARGEFILE) = 6
[pid 20183] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.so", O_RDONLY|O_LARGEFILE) = 6
[pid 20183] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.so", O_RDONLY|O_LARGEFILE) = 6
[pid 20183] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.so", O_RDONLY|O_LARGEFILE) = 6
[pid 20183] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.so", O_RDONLY|O_LARGEFILE) = 6
[pid 20183] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.so", O_RDONLY|O_LARGEFILE) = 6
[pid 20183] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.so", O_RDONLY|O_LARGEFILE) = 6
[pid 20183] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.so", O_RDONLY|O_LARGEFILE) = 6
[pid 20183] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.so", O_RDONLY|O_LARGEFILE) = 6
[pid 20183] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.so", O_RDONLY|O_LARGEFILE) = 6
[pid 20183] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.so", O_RDONLY|O_LARGEFILE) = 6
[pid 20183] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.so", O_RDONLY|O_LARGEFILE) = 6
[pid 20183] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.so", O_RDONLY|O_LARGEFILE) = 6
[pid 20183] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.so", O_RDONLY|O_LARGEFILE) = 6
[pid 20183] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.so", O_RDONLY|O_LARGEFILE) = 6
[pid 20183] open("/home/sandy/gnome-shell/install/lib/libgirepository-1.0.so", O_RDONLY|O_LARGEFILE) = 6
[pid 20212] open("/home/sandy/gnome-shell/source/gir-repository/gir/.libs/libgirepository-1.0.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 20212] open("/usr/lib/tls/libgirepository-1.0.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 20212] open("/usr/lib/libgirepository-1.0.so.0", O_RDONLY) = 4
[pid 20213] open("/home/sandy/gnome-shell/source/gir-repository/gir/.libs/libgirepository-1.0.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 20213] open("/usr/lib/tls/libgirepository-1.0.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 20213] open("/usr/lib/libgirepository-1.0.so.0", O_RDONLY) = 4


Uninstalling the libgirepository-1_0-0 package made the error go away (of course, this removed seed, gnome-games, epiphany, etc).
Comment 1 Colin Walters 2010-01-04 19:36:19 UTC
This kind of thing is amazingly hard to debug; my guess is something in the stack is overwriting LD_LIBRARY_PATH incorrectly, but I don't see that being done currently in gobject-introspection or gir-repository at least.
Comment 2 Colin Walters 2010-02-23 20:36:20 UTC
Note suggested workaround: remove gir-repository from system install paths.
Comment 3 Giuseppe Fuggiano 2010-04-09 21:14:13 UTC
Created attachment 158329 [details]
make with error

Hi there,

I have something like that here. Using jhbuild, linking stops at gobject-introspection because of missing symbols.  I realized it was looking at the wrong path (my system /usr/lib path), then I discovered that the issue was caused by a wrong order in LD_LIBRARY_PATH in the file Gio-2.0 (wrapper to .libs/Gio-2.0 ELF binary) generated by the libtool script.  Modifying this one at the related line, I was able to control the order in LD_LIBRARY_PATH in Gio-2.0 wrapper script and having a straitforward linking.

But the same trouble happened at the next module...

I think it's a libtool or autoconf/automake issue.

Attaching my affected 'make'.  Hope this help.

Giuseppe
Comment 4 Federico Mena Quintero 2010-06-11 18:36:27 UTC
I used to have a libgirepository RPM installed as part of the gobject-introspection meta-RPM in openSUSE, just like Sandy.

However, when *that* is present, gobject-introspection fails to build under jhbuild (and probably also fails if you build it by hand):

[jhbuild] linux-7b5d$ make V=1
env LPATH=.libs PYTHONPATH=..:.. UNINSTALLED_INTROSPECTION_SRCDIR=.. UNINSTALLED_INTROSPECTION_BUILDDIR=.. ../tools/g-ir-scanner --verbose -I.. --add-include-
path=. --add-include-path=../gir --add-include-path=. --add-include-path=../gir --namespace=Everything --nsversion=1.0 --libtool="/bin/sh ../libtool"  --libra
ry=libgirepository-everything-1.0.la --pkg=gobject-2.0 --pkg=cairo --pkg=gio-2.0 --include=GObject-2.0 --include=cairo-1.0 --include=Gio-2.0    everything.h e
verything.c Gio-2.0.gir libgirepository-everything-1.0.la --output Everything-1.0.gir
introspecting class TestObj
Traceback (most recent call last):
  • File "../tools/g-ir-scanner", line 38 in <module>
    sys.exit(scanner_main(sys.argv))
  • File "/home/federico/jhbuild/src/gobject-introspection/giscanner/scannermain.py", line 323 in scanner_main
    namespace = glibtransformer.parse()
  • File "/home/federico/jhbuild/src/gobject-introspection/giscanner/glibtransformer.py", line 159 in parse
    self._execute_binary()
  • File "/home/federico/jhbuild/src/gobject-introspection/giscanner/glibtransformer.py", line 318 in _execute_binary
    self._read_introspect_dump(out_path)
  • File "/home/federico/jhbuild/src/gobject-introspection/giscanner/glibtransformer.py", line 330 in _read_introspect_dump
    self._introspect_type(child)
  • File "/home/federico/jhbuild/src/gobject-introspection/giscanner/glibtransformer.py", line 696 in _introspect_type
    self._introspect_object(xmlnode)
  • File "/home/federico/jhbuild/src/gobject-introspection/giscanner/glibtransformer.py", line 733 in _introspect_object
    parent_type_names = xmlnode.attrib['parents'].split(',')
KeyError: 'parents'
make: *** [Everything-1.0.gir] Error 1  

Some interesting things:

- No file in gir/tmp-introspectXXXX/* contained the "parents" string.

- In that directory, dump.xml had <class name="TestObj" get-type="test_obj_get_type" parent="GObject"> - but not "parents" - maybe that is created by the older, system-installed libgirepository.so.

- The binaries in gobject-introspection/tools/.libs are linked to /usr/lib/libgirepository*.so - or so ldd reports.  This looks wrong, but I'm not sure if that path is supposed to change if you actually run those binaries through libtool's wrapper scripts.

I couldn't figure out if something was wrong libtool-wise.  Maybe when running the tools/ binaries, they need to be called explicitly with "libtool --mode=execute" or something.  I had to "rpm -e" the libgirepository RPM; then rebuilding gobject-introspection actually worked.
Comment 5 Colin Walters 2010-06-15 13:05:27 UTC
*** Bug 621500 has been marked as a duplicate of this bug. ***
Comment 6 Colin Walters 2010-06-15 18:57:48 UTC
Random guess: this occurs when the scanner is run outside of jhbuild, for example:

$ jhbuild run ./configure --prefix=...
$ make

As opposed to what I do which:

$ jhbuild run ./configure --prefix
$ jhbuild run make

In the first, LD_LIBRARY_PATH is not set, so we'll be picking up the system libgirepository.so.  In the latter, we grab the one from the development root.

The only fix I can think of here is to have the scanner detect where it's installed, and make a last ditch effort to synthesize a LD_LIBRARY_PATH from that.  This gets into lib/lib64 hell though.
Comment 7 Federico Mena Quintero 2010-06-15 20:55:04 UTC
(In reply to comment #6)
> Random guess: this occurs when the scanner is run outside of jhbuild, for
> example:
> 

I'm 99% sure that I only ran things from "jhbuild build" or "jhbuild shell" when I was trying to debug this.

Even selecting the "wipe directory and start over" option didn't work as long as the system's version of the library was installed.

But it worked on another box with the system library installed.  Go figure.
Comment 8 Michael Meeks 2010-06-25 10:34:31 UTC
Sadly; same problem here - this is not good (TM) ;-) wasted a day or so.

With a bit of debugging - it seems like we compile some magic C program:

/usr/opt/hgnome/src/pango/pango/tmp-introspectQe9RKo/PangoXft-1.0

which mercifully is not deleted on failure; so you can see it is a libtool wrapper, it contains the immortal line:

  if test -f "$progdir/$program"; then
    # Add our own library path to LD_LIBRARY_PATH
    LD_LIBRARY_PATH="/opt/hgnome/src/pango/pango/.libs:/usr/opt/hgnome/src/pango/pango/.libs:/usr/lib:/opt/hgnome/lib:$LD_LIBRARY_PATH"

which matches the strace madness:

25400 open("/opt/hgnome/src/pango/pango/.libs/libgirepository-1.0.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
25400 open("/usr/opt/hgnome/src/pango/pango/.libs/libgirepository-1.0.so.0", O_RDONLY) = -1 ENOENT (No such file or directory)
25400 open("/usr/lib/libgirepository-1.0.so.0", O_RDONLY) = 4

which in turn is created by libtool:

25198 execve("/bin/sh", ["/bin/sh", "../libtool", "--mode=link", "--tag=CC", "--silent", "gcc", "-o", "/usr/opt/hgnome/src/pango/pango/tmp-introspectQe9RKo/PangoXft-1.0", "-L.", "libpangoxft
-1.0.la", "-pthread", "-Wl,--export-dynamic", "-L/opt/hgnome/lib", "-lgio-2.0", "-lgirepository-1.0", "-lffi", "-lgobject-2.0", "-lgmodule-2.0", "-lgthread-2.0", "-lrt", "-lglib-2.0", "/usr/
opt/hgnome/src/pango/pango/tmp-introspectQe9RKo/PangoXft-1.0.o"

Which oddly enough looks just fine. The jhbuild shell environment contains:

$ echo $LD_LIBRARY_PATH 
/opt/hgnome/lib:/usr/lib/mpi/gcc/openmpi/lib

which looks ok too. So - where does that bogus /usr/lib come from ? :-)
Comment 9 Michael Meeks 2010-06-25 10:50:41 UTC
This is written by the libtool script here:

	# Export our shlibpath_var if we have one.
	if test "$shlibpath_overrides_runpath" = yes && test -n "$shlibpath_var" && test -n "$temp_rpath"; then
	  $ECHO "\
    # Add our own library path to $shlibpath_var
    $shlibpath_var=\"$temp_rpath\$$shlibpath_var\"

debug shows $temp_rpath contains the /usr/lib corruption.
Comment 10 Michael Meeks 2010-06-25 11:02:57 UTC
Hmm; as the temp_rpath is built up, I added some debug and (it seems) the badness comes from:

	    # We need to hardcode the library path
	    if test -n "$shlibpath_var" && test -z "$avoidtemprpath" ; then
	      # Make sure the rpath contains only unique directories.
	      case "$temp_rpath:" in
	      *"$absdir:"*) ;;
	      *) temp_rpath="$temp_rpath$absdir:" ;;
	      esac
	    fi

+	    echo "temp rpath contains: '$temp_rpath' from '$absdir' '$libdir' '$deplib'" >> /dev/stderr

	    # Hardcode the library path.
	    # Skip directories that are in the system default run-time

yielding:
...
temp rpath contains: '/opt/hgnome/src/pango/pango/.libs:/usr/opt/hgnome/src/pango/pango/.libs:/usr/lib:' from '/usr/lib' '/usr/lib' '/usr/lib/libXrender.la'

Interestingly; the compile and link rpaths have this system badness removed from them, but not the temp_rpath that we use; most odd.

I seem to have libtool-2.2.6 installed by both bootstrap, and packaged locally; urk ! ... ;-(
Comment 11 Michael Meeks 2010-06-25 11:29:04 UTC
Weell ... it seems it is possible / easy to work around this by ensuring we pass the .la files to libtool -after- the libraries that we want to link from pkgconfig; thus:

diff --git a/giscanner/dumper.py b/giscanner/dumper.py
index 14540d9..813b0ef 100644
--- a/giscanner/dumper.py
+++ b/giscanner/dumper.py
@@ -197,6 +197,7 @@ class DumpCompiler(object):
         # Search the current directory first
         args.append('-L.')
 
+        libtool_args = []
         uninst_builddir = os.environ.get('UNINSTALLED_INTROSPECTION_BUILDDIR')
         # hack for building GIRepository.gir, skip -lgirepository-1.0 since
         # libgirepository-1.0.la is not in current directory and we refer to it
@@ -206,7 +207,7 @@ class DumpCompiler(object):
                 self._options.libraries[0] == 'girepository-1.0'):
                 continue
             if library.endswith(".la"): # explicitly specified libtool library
-                args.append(library)
+                libtool_args.append(library)
             else:
                 args.append('-l' + library)
 
@@ -221,6 +222,8 @@ class DumpCompiler(object):
             if not os.path.exists(source):
                 raise CompilerError(
                     "Could not find object file: %s" % (source, ))
+        # need to be late - cf. bug#605156
+        args.extend(libtool_args);
         args.extend(list(sources))
 
         subprocess.check_call(args)


Review / permission to commit appreciated :-)
Comment 12 Colin Walters 2010-06-25 12:10:26 UTC
(In reply to comment #11)
> Weell ... it seems it is possible / easy to work around this by ensuring we
> pass the .la files to libtool -after- the libraries that we want to link from
> pkgconfig; thus:

Thanks a lot for looking at this Michael, and I apologize for the lost time debugging it; I know debugging twisted build stuff is really painful.

I actually had a similar realization about the library ordering yesterday when someone else hit this but didn't get a chance to commit a fix.  Yours is blunt but that's fine by me; it seems exceedingly unlikely that someone is going to want to link a libtool library before a regular one (and actually I'm fine not supporting that).

So go ahead and commit.  I'm going to attach a different patch to this bug which I think would also fix it.
Comment 13 Colin Walters 2010-06-25 12:10:52 UTC
Created attachment 164614 [details] [review]
Move pkg-config calls before --library and --program

We need our just-built library path to override what we have
from pkg-config.
Comment 14 Michael Meeks 2010-06-25 13:58:23 UTC
Ho hum; well my 'fix' seems to cause other problems, or at least I stumble upon other XML weirdness when I use my patch; so yours looks rather better ;-)

Things like this:

  GISCAN Pango-1.0.gir
/usr/opt/hgnome/src/pango/pango/pango-color-table.h:762: syntax error, unexpected identifier in '    guint16 name_offset;' at 'guint16'
/usr/opt/hgnome/src/pango/pango/pango-color-table.h:768: syntax error, unexpected identifier, expecting ',' or ';' in 'static const ColorEntry color_entries[] = {' at 'color_entries'
/usr/opt/hgnome/src/pango/pango/pango-language-sample-table.h:52: syntax error, unexpected identifier in 'LANGUAGE(' at 'LANGUAGE'
  GISCAN PangoFT2-1.0.gir
  GISCAN PangoXft-1.0.gir
Traceback (most recent call last):
  • File "/opt/hgnome/bin/g-ir-scanner", line 38 in <module>
    sys.exit(scanner_main(sys.argv))
  • File "/opt/hgnome/lib/gobject-introspection/giscanner/scannermain.py", line 331 in scanner_main
    namespace = glibtransformer.parse()
  • File "/opt/hgnome/lib/gobject-introspection/giscanner/glibtransformer.py", line 149 in parse
    self._execute_binary()
  • File "/opt/hgnome/lib/gobject-introspection/giscanner/glibtransformer.py", line 307 in _execute_binary
    self._read_introspect_dump(out_path)
  • File "/opt/hgnome/lib/gobject-introspection/giscanner/glibtransformer.py", line 319 in _read_introspect_dump
    self._introspect_type(child)
  • File "/opt/hgnome/lib/gobject-introspection/giscanner/glibtransformer.py", line 687 in _introspect_type
    self._introspect_object(xmlnode)
  • File "/opt/hgnome/lib/gobject-introspection/giscanner/glibtransformer.py", line 723 in _introspect_object
    parent_type_names = xmlnode.attrib['parents'].split(',')
KeyError: 'parents'

Sigh. Is it only me that suffers these extrem fragility problems, and/or gets nervous about this heap of python in the build process ? ;-)
Comment 15 Colin Walters 2010-06-25 14:02:26 UTC
Comment on attachment 164614 [details] [review]
Move pkg-config calls before --library and --program

Attachment 164614 [details] pushed as def3d91 - Move pkg-config calls before --library and --program
Comment 16 Michael Meeks 2010-06-25 14:40:34 UTC
Altering the g-ir-scanner argument order has no effect on the ultimate libtool argument order it seems (sadly).

Pushed - with your fix too Colin.
Comment 17 Johan (not receiving bugmail) Dahlin 2010-06-25 14:47:00 UTC
(In reply to comment #14)
> Ho hum; well my 'fix' seems to cause other problems, or at least I stumble upon
> other XML weirdness when I use my patch; so yours looks rather better ;-)
> 
> Things like this:
> 
>   GISCAN Pango-1.0.gir
> /usr/opt/hgnome/src/pango/pango/pango-color-table.h:762: syntax error,
> unexpected identifier in '    guint16 name_offset;' at 'guint16'
> /usr/opt/hgnome/src/pango/pango/pango-color-table.h:768: syntax error,
> unexpected identifier, expecting ',' or ';' in 'static const ColorEntry
> color_entries[] = {' at 'color_entries'
> /usr/opt/hgnome/src/pango/pango/pango-language-sample-table.h:52: syntax error,
> unexpected identifier in 'LANGUAGE(' at 'LANGUAGE'
>   GISCAN PangoFT2-1.0.gir
>   GISCAN PangoXft-1.0.gir
> Traceback (most recent call last):
> 

This is the same problem, the xml generated by the tmp-introspect program is using libgirepository.so from /usr/lib and not from the prefix.
Comment 18 Tommi Komulainen 2010-06-25 17:18:51 UTC
hmm, maybe I misunderstood something but don't you want .la files (built as part of your own package) *before* system libraries, topmost dependency first, so that the linker prefers the in-tree version instead of whichever old version is already installed?

or at least that was the right order in LIBADD/LDADD automake variables
Comment 19 Colin Walters 2010-06-25 18:28:25 UTC
(In reply to comment #18)
> hmm, maybe I misunderstood something but don't you want .la files (built as
> part of your own package) *before* system libraries, topmost dependency first,
> so that the linker prefers the in-tree version instead of whichever old version
> is already installed?
> 
> or at least that was the right order in LIBADD/LDADD automake variables

Yes - this patch appears to break things for me, because the generated binary has an RPATH which lists my $PREFIX first, and that means it picks up the old library.

I think the problem people are running into here that we actually need the library path order to be:

.:$BUILD_ROOT:/usr

We're not actually trying to link the generated binary against the $PREFIX libgirepository.  I'm going to try making a patch which reverts this one, and does that.
Comment 20 Colin Walters 2010-06-25 18:59:37 UTC
Created attachment 164648 [details] [review]
Revert "fix bug#605156 by ordering libtool archives that may pull in system"

This reverts commit e14bdebab725263c3d6f97267090cbf5d06b99d2.  While
that commit fixed things in some cases, it broke others.  I think the
problem people are running into here that we actually need the library
path order to be:

.:$BUILD_ROOT:/usr

Ensure that the middle happens by explicitly calling pkg-config.
Comment 21 Colin Walters 2010-06-25 18:59:57 UTC
Michael can you try this new patch?
Comment 22 Michael Meeks 2010-06-28 11:32:12 UTC
Seems to work for me; it'd be good to get in [ given my breakage I guess ]. Ultimately, though I'm prodding the libtool maintainers - since it seems the underlying problem affects other things, and we can't even run simple apps like gtk-query-immodules-2.0 inside the build tree with system X server .la files with the world in it's current state - which is lamer than lame :-)
Comment 23 Colin Walters 2010-06-28 15:19:52 UTC
Attachment 164648 [details] pushed as 8c48a31 - Revert "fix bug#605156 by ordering libtool archives that may pull in system"
Comment 24 Colin Walters 2010-06-28 15:20:32 UTC
I think the .la files should be deleted at the RPM layer, don't ship them for system packages.
Comment 25 André Klapper 2015-02-07 16:55:47 UTC
[Mass-moving gobject-introspection tickets to its own Bugzilla product - see bug 708029. Mass-filter your bugmail for this message: introspection20150207 ]