Created attachment 191323 [details] [review]
Revert "Clean .la files post-install"

(In reply to comment #0)
> .la files are useless and harmful *when they are in /usr/lib[64]*.
> However, when they are in a directory that is not part of the ldconfig
> configuration (eg, a subdir of /usr/lib[64],

Only if the software is using libltdl, right?  

> or a jhbuild prefix)

Why are they necessary in a jhbuild prefix?

I need a more concrete example of what broke.  I definitely understand if you had a jhbuild with a lot of configured modules that had detected the .la files, you need to do a full rebuild.  

But it shouldn't affect new builders.

(In reply to comment #2)
> Only if the software is using libltdl, right?  

no

> Why are they necessary in a jhbuild prefix?

When linking a library, libtool will only include rpath information if there is a .la file telling it to. So if you remove .la files from the gnome-shell install prefix, then libtool won't include any rpath information in libgnome-shell.so or gnome-shell-real, and so if you try to run gnome-shell without using "jhbuild run", it will look for all of the libraries in /usr/lib64 instead of ${gnome_shell_prefix}/lib64, and fail if it can't find them. This was causing a problem because we were linking against libgweather-3.so.0.0.2 in the gnome-shell prefix, but /usr only had libgweather-3.so.0.0.0 (or something).

However, even if you used jhbuild run, it still was unable to find libbluetooth-applet.so, because that was in a private directory. With libbluetooth-applet.la there, libtool would have included the rpath information in the binary and so the library would have been found, but without that, it doesn't do that. (Note that Fedora keeps some .la files in subdirectories of /usr/lib64. It's only the ones in /usr/lib64 itself that get removed.)

(In reply to comment #3)
> But it shouldn't affect new builders.

It does. (In fact, it primarily affects new builders since old builders don't generally update their jhbuild checkout and so are still using an older version). Just rm -rf your gnome-shell install prefix and then do a complete build, and it will fail when trying to compile Shell-0.1.typelib (and if you work past that, then it used to fail again when you tried to run gnome-shell, but it looks like f15 may now have new enough packages that it won't [until some library bumps its so number in git again]).

(In reply to comment #4)
> (In reply to comment #2)
> > Only if the software is using libltdl, right?  
> 
> no

I assume the rationale is the same as the one below:

> > Why are they necessary in a jhbuild prefix?
> 
> When linking a library, libtool will only include rpath information if there is
> a .la file telling it to. 



So if you remove .la files from the gnome-shell
> install prefix, then libtool won't include any rpath information in
> libgnome-shell.so 

.so files can't have rpaths.

> or gnome-shell-real, and so if you try to run gnome-shell
> without using "jhbuild run"

That's just broken, sorry.  You basically always need to be inside "jhbuild shell" or things in general are just going to fail (think typelib paths for example).
 
> However, even if you used jhbuild run, it still was unable to find
> libbluetooth-applet.so, because that was in a private directory. With
> libbluetooth-applet.la there, libtool would have included the rpath information
> in the binary and so the library would have been found, but without that, it
> doesn't do that. (Note that Fedora keeps some .la files in subdirectories of
> /usr/lib64. It's only the ones in /usr/lib64 itself that get removed.)

Note that I fixed this in a different way in commit f71afa924; basically this use of the .la files is trying to do what pkg-config does.  But we have pkg-config, so we can just use that.

> It does. (In fact, it primarily affects new builders since old builders don't
> generally update their jhbuild checkout and so are still using an older
> version). Just rm -rf your gnome-shell install prefix and then do a complete
> build, and it will fail when trying to compile Shell-0.1.typelib (and if you
> work past that, then it used to fail again when you tried to run gnome-shell,
> but it looks like f15 may now have new enough packages that it won't [until
> some library bumps its so number in git again]).

I don't understand that.  And yes, it does work for me.

(In reply to comment #0)
> subdir of /usr/lib[64], 

I agree there is a bug here if software is using libltdl, so we should only be removing .la files from the main libdirs to be safe.  (However, really any GNOME software should be using GLib's g_module_* functions which don't need .la files).

(In reply to comment #5)
> > or gnome-shell-real, and so if you try to run gnome-shell
> > without using "jhbuild run"
> 
> That's just broken, sorry.  You basically always need to be inside "jhbuild
> shell" or things in general are just going to fail (think typelib paths for
> example).

We need to stop having this argument every six months. You are not supposed to be required to say "jhbuild run gnome-shell". The wiki says so, and this has been the case for almost forever. (Eg, gnome-shell-jhbuild sets GI_TYPELIB_PATH, so typelibs are found fine.)

If we're changing that, then you should update the documentation, and remove all of the parts of gnome-shell-jhbuild that try to make it otherwise, so that it will fail more spectacularly instead of almost working.

> Note that I fixed this in a different way in commit f71afa924

ah, hence it working for you when you build it.

> basically this
> use of the .la files is trying to do what pkg-config does.  But we have
> pkg-config, so we can just use that.

Shrug. libtool was already solving this problem without causing any other problems.

(In reply to comment #7)
>
> We need to stop having this argument every six months. You are not supposed to
> be required to say "jhbuild run gnome-shell". The wiki says so, and this has
> been the case for almost forever. (Eg, gnome-shell-jhbuild sets
> GI_TYPELIB_PATH, so typelibs are found fine.)

I just changed the wiki page to say:
$ jhbuild shell
$ gnome-shell --replace

i.e. not uninstalled, and running explicitly under jhbuild shell.

> If we're changing that, then you should update the documentation, 

Done!

> and remove
> all of the parts of gnome-shell-jhbuild that try to make it otherwise, so that
> it will fail more spectacularly instead of almost working.

We'd have to explicitly agree to kill the run-uninstalled-but-not-in-jhbuild case (which I want to do, since really - just ugh).

(In reply to comment #8)
> I just changed the wiki page to say:
> $ jhbuild shell
> $ gnome-shell --replace

it's really better to do "jhbuild run gnome-shell --replace". The user is not going to remember that they're still in a jhbuild shell after gnome-shell exits.

Anyway, this will bring back bug 592943...

(In reply to comment #9)
> (In reply to comment #8)
> > I just changed the wiki page to say:
> > $ jhbuild shell
> > $ gnome-shell --replace
> 
> it's really better to do "jhbuild run gnome-shell --replace". The user is not
> going to remember that they're still in a jhbuild shell after gnome-shell
> exits.

It's a jhbuild user understanding issue; it deserves an explanation in the manual.  I'll look at that.

> Anyway, this will bring back bug 592943...

We no longer build xulrunner, so that's not a problem.  And note this won't bring it *back*; it still exists, we never stopped setting LD_LIBRARY_PATH.

Created attachment 191363 [details] [review]
postinstall: Only clean toplevel .la files

This is safer - a program *could* be using libltdl to load .la files,
and .la files at the toplevel are the ones that can actually cause
*problems*, whereas ones in subdirs are just cruft.

Also log a message when we do this.

Created attachment 191379 [details] [review]
postinstall: Only clean toplevel .la files

Fix a bug where we were cleaning the jhbuild prefix, not the temporary
DESTDIR.

Attachment 191379 [details] pushed as 90287e2 - postinstall: Only clean toplevel .la files