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 623952 - .la files cause linking against wrong glib
.la files cause linking against wrong glib
Status: RESOLVED NOTGNOME
Product: gnome-shell
Classification: Core
Component: building
2.31.x
Other Linux
: Normal blocker
: ---
Assigned To: gnome-shell-maint
gnome-shell-maint
: 624505 625131 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2010-07-09 15:17 UTC by Kenny Strawn
Modified: 2011-03-25 19:04 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Kenny Strawn 2010-07-09 15:17:43 UTC
When I tried rebuilding GNOME Shell (jhbuild build -fac), JHBuild suddenly errored out on me, on Ubuntu 10.10 Alpha 2.

Here is the output of jhbuild's execution of make just before the error:

/home/kenny_strawn/gnome-shell/install/lib/libgtk-x11-3.0.so: undefined reference to `g_variant_new_bytestring_array'
/home/kenny_strawn/gnome-shell/install/lib/libgio-2.0.so: undefined reference to `g_variant_new_bytestring'
/home/kenny_strawn/gnome-shell/install/lib/libgio-2.0.so: undefined reference to `g_variant_get_bytestring'

This obviously indicates a syntax error in GNOME Shell's code that needs to be fixed.
Comment 1 Lee Wilson 2010-07-09 15:50:51 UTC
Can I also add that this is failing since yesterday (8/July) on Ubuntu 9.10 and 10.04 also, with the same crash during the build process.

http://pastebin.com/uhrsXFgi
Comment 2 Florian Müllner 2010-07-09 18:25:36 UTC
(In reply to comment #0)
> This obviously indicates a syntax error in GNOME Shell's code that needs to be
> fixed.

Unfortunately this is not true - those functions are
 (1) part of the stack built by jhbuild (glib to be exact)
 (2) not used directly in gnome-shell

The error has been reported by several users on IRC, all of them using Ubuntu. I have to admit that it's still a complete mystery to me ...
Comment 3 Lee Wilson 2010-07-10 09:54:21 UTC
From the IRC channel, I just built gnome-shell for the first time in 2 days (woo)


remove all .la files from /usr/lib/

gnome-shell now builds once again on ubuntu 9.10
Comment 4 Kenny Strawn 2010-07-10 10:23:55 UTC
Same here. I have Ubuntu 10.10 Alpha 2.
Comment 5 Kenny Strawn 2010-07-10 10:29:55 UTC
I also wanted to add that I chose to rm -rf the GNOME Shell directory and start over.
Comment 6 Aaron Hankin 2010-07-10 20:38:19 UTC
Rebuilding from scratch has not fixed the problem for me. I still see the same error message with a bunch of 'undefined references' (several more than the original reporter listed but along the same line).
Comment 7 Steven Van Bael 2010-07-10 21:56:30 UTC
I tried moving all the .la files yesterday night but did not remove the gnome-shell folder and in that case the undefined references popped up again.

Tonight I re-removed all .la files from /usr/lib/ and deleted the gnome-shell folder. This way I was able to build successfully again on Ubuntu 10.04

What I did:

mv /usr/lib/*.la ~/backup/
rm -Rf ~/gnome-shell
bash gnome-shell-build-setup.sh
jhbuild build
Comment 8 asubedi 2010-07-11 00:41:36 UTC
I can confirm that steps prescribed by Steven Van Bael works.
Comment 9 Aaron Hankin 2010-07-11 15:23:00 UTC
Do other programs need those lib/*.la files? Is it really something I want to remove or will it end up breaking some other program in my system?
Comment 10 Dean Loros 2010-07-11 16:22:49 UTC
I can also confirm that removing all the .la files from /usr/lib allows the shell to do a complete build without errors. I had been trying without success for several days to do a complete build---the make always stalled during making test-theme--I had cleared all of the other errors. There is still a problem with the gnome-shell-build-setup.sh--it will not pickup several .dev files in my testing Maverick 10.10 install.

Using Steven's "fix"
Comment 11 Florian Müllner 2010-07-11 17:00:22 UTC
(In reply to comment #9)
> Do other programs need those lib/*.la files? Is it really something I want to
> remove or will it end up breaking some other program in my system?

Those files are needed when building the libraries (e.g. libglib-2.0.la is needed while building libglib-2.0.so). They are neither needed at runtime (note that they are installed by the libXXX-dev package) nor when building a program which depends on the library. So no, removing those files won't break programs - messing with files under the control of the package manager is still extremely ugly though.

A somewhat nicer alternative would be to install glib/gtk+-3.0 from a PPA and set up jhbuild to skip those modules.
Comment 12 Kenny Strawn 2010-07-11 21:34:42 UTC
Here's what I did:

[kenny-strawn@ubuntu:~]$ sudo rm -rf ~/gnome-shell && jhbuild build -fac

This completely removes the GNOME Shell source directory and allows the user to start on a clean slate.
Comment 13 Leslie Nooland 2010-07-15 15:43:30 UTC
Basically I removed all the *.la files from /home/username/gnome-shell/install/lib, and it worked.
Comment 14 Florian Müllner 2010-07-16 06:36:46 UTC
*** Bug 624505 has been marked as a duplicate of this bug. ***
Comment 15 Luis Villa 2010-07-18 23:00:49 UTC
I did what Leslie suggested; that didn't work by itself, but doing that + rebuilding glib (libgio) worked. Sounds like this is maybe a WONTFIX; just rm -rf your build tree and start fresh kind of thing.
Comment 16 sathyz 2010-07-20 04:31:57 UTC
(In reply to comment #7)

> mv /usr/lib/*.la ~/backup/
> rm -Rf ~/gnome-shell
> bash gnome-shell-build-setup.sh
> jhbuild build

I am able to build only by following these steps, won't this affect the current Ubuntu (10.04)/GNOME installation?
Comment 17 Florian Müllner 2010-07-20 09:44:36 UTC
(In reply to comment #16)
> I am able to build only by following these steps, won't this affect the current
> Ubuntu (10.04)/GNOME installation?

Only in the sense that you removed files the package manager assumes to be there (because their packages were installed, but not uninstalled).

On a side note: Debian has apparently decided to remove those files eventually: http://wiki.debian.org/ReleaseGoals/LAFileRemoval
Comment 18 drago01 2010-07-23 16:05:22 UTC
*** Bug 625131 has been marked as a duplicate of this bug. ***
Comment 19 Diska 2010-07-23 16:15:45 UTC
now i can't compile gobject-introspectin

CCLD   libgirepository-everything-1.0.la
/bin/sed: can't read /usr/lib/libfreetype.la: No such file or directory
Comment 20 Diska 2010-07-23 16:18:36 UTC
with a wipe it's gone
Comment 21 Pablo Castellano (IRC: pablog) 2010-07-25 23:08:21 UTC
the same building NetworkManager, but deleting libglib-2.0.la didn't work.


/home/pablo/opt/gnome2/lib/libgio-2.0.so: undefined reference to `g_variant_new_bytestring'
/home/pablo/opt/gnome2/lib/libgio-2.0.so: undefined reference to `g_variant_new_bytestring_array'
/home/pablo/opt/gnome2/lib/libgio-2.0.so: undefined reference to `g_variant_get_bytestring'

vs


libtool: link: cannot find the library `/home/pablo/opt/gnome2/lib/libglib-2.0.la' or unhandled argument `/home/pablo/opt/gnome2/lib/libglib-2.0.la'
Comment 22 Leslie Nooland 2010-08-31 13:17:21 UTC
well, it seems this bug is still here so i wanna share my solution.

i do: 

rm -rf ~/gnome-shell/install/lib/*.la

after that when i try to jhbuild buildone gnome-shell it will complain about some missing .la files. that error is fixed like this:

jhbuild buildone gtk3 -acf

jhbuild buildone clutter -acf

after these two, i do again:

jhbuild buildone gnome-shell

and all works fine.

Ubuntu Lucid.

p.s. i tried removing the gnome-shell directory, but the error wont go away.
Comment 23 Diska 2010-08-31 13:20:15 UTC
this work with a new installation too ?( compile all dependence packages )
Comment 24 Dan Winship 2010-08-31 13:32:33 UTC
(In reply to comment #22)
> well, it seems this bug is still here

Yes, because it's a bug *in libtool*. Most likely, in between builds, you upgraded some package, thus restoring its .la file in /usr/lib, thus triggering the problems again.
Comment 25 scientica 2011-01-11 11:52:10 UTC
Confirming issue and workaround on gentoo and Gtk+ 3.

(Re)moving all libtool archive files (.la) from /opt/gnome/lib*/ and /usr/lib also solves the build failure of Gtk+-3 when it fails with g_application_get_type when generating the Gtk .gir file.
I found out that it tried to use the system's glib by sandboxing the build, seems like a libtool bug, it generated a LD_LIBRARY_PATH with /usr/lib before the opt-gnome, reversing the order solved manual building. (Funny thing is that there was a comment in the libtool wrapper that explicitly said it prepended things to override the system, but it might have refered to the two paths before /usr/lib)
(btw, I'm using gentoo, jhbuild and libtool v2.2.10, if that's of any relevance)

Should this workaround be listed somewhere on <http://live.gnome.org/JhbuildIssues/>? I'm guessing /General would be the place as it seems to affect "random" modules (depending on the build system's .la files)
Comment 26 Jasper St. Pierre (not reading bugmail) 2011-01-11 14:38:02 UTC
The workaround is on http://live.gnome.org/GnomeShell/RemovingLaFiles, and it's listed from http://live.gnome.org/GnomeShell/SwatList. I just edited and cleaned up the Building section in http://live.gnome.org/GnomeShell#building to make the issue a bit more obvious
Comment 27 scientica 2011-01-11 16:29:11 UTC
Great, perhaps <http://library.gnome.org/devel/jhbuild/stable/getting-started.html.en> also could have have a link to the list in the "Using JHBuild" section? (Or elsewhere in the JHBuild docs)
Comment 28 Jasper St. Pierre (not reading bugmail) 2011-01-11 16:32:36 UTC
This bug is not specific to jhbuild, nor is it related to jhbuild. It's a libtool bug.
Comment 29 Dan Winship 2011-01-11 17:03:23 UTC
it's "related to jhbuild" in the sense that jhbuild is a system designed for doing *exactly* the thing that triggers the libtool bug
Comment 30 Dan Winship 2011-03-25 19:04:45 UTC
the only reason for keeping this bug open was to point people to it when they had this problem, but we point them to the wiki instead. so...