.la files

classic Classic list List threaded Threaded
13 messages Options
Reply | Threaded
Open this post in threaded view
|

.la files

Ross Burton
Hi,

I'm sure most of us agree that .la files are truly evil, but removing
them from the archive is somewhat tricky.  As we've seen with the recent
Xcursor debacle, you can't just remove them from lower libraries without
everything above it falling apart.

I propose that pkg-gnome take the bold step of refusing to ship .la
files, and start their removal straight away.  To be polite this should
be done from the higher level libraries downwards: I've just removed
the .la file from libloudmouth1-dev, as I don't believe anything will be
effected.  We could probably remove the .la files from
evolution-data-server in the next upload, as I also think that would be
safe.  In this manner we can slowly remove the files until we're all the
way down to GTK+, and finally we will be free!  Free of the cursed files
of doom!

Comments?

Ross
--
Ross Burton                                 mail: [hidden email]
                                          jabber: [hidden email]
                                     www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF


signature.asc (198 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: .la files

Loïc Minier
On Fri, May 05, 2006, Ross Burton wrote:
> I propose that pkg-gnome take the bold step of refusing to ship .la
> files, and start their removal straight away.  To be polite this should
> be done from the higher level libraries downwards: I've just removed
> the .la file from libloudmouth1-dev, as I don't believe anything will be
> effected.  We could probably remove the .la files from
> evolution-data-server in the next upload, as I also think that would be
> safe.  In this manner we can slowly remove the files until we're all the
> way down to GTK+, and finally we will be free!  Free of the cursed files
> of doom!

 Yep, this has started already, I've removed them from some packages
 which have not yet been uploaded but are leaf libraries.  I'm not sure
 e-d-s qualifies as such though, but it depends what in e-d-s.

--
Loïc Minier <[hidden email]>
"You can gtk_main_run, but you can't gtk_widget_hide." --danw, 19-jul-04


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: .la files

Ross Burton
On Fri, 2006-05-05 at 17:57 +0200, Loïc Minier wrote:

> On Fri, May 05, 2006, Ross Burton wrote:
> > I propose that pkg-gnome take the bold step of refusing to ship .la
> > files, and start their removal straight away.  To be polite this should
> > be done from the higher level libraries downwards: I've just removed
> > the .la file from libloudmouth1-dev, as I don't believe anything will be
> > effected.  We could probably remove the .la files from
> > evolution-data-server in the next upload, as I also think that would be
> > safe.  In this manner we can slowly remove the files until we're all the
> > way down to GTK+, and finally we will be free!  Free of the cursed files
> > of doom!
>
>  Yep, this has started already, I've removed them from some packages
>  which have not yet been uploaded but are leaf libraries.  I'm not sure
>  e-d-s qualifies as such though, but it depends what in e-d-s.
On the assumption that Dapper contains most of Sid:

$ grep-dctrl -sPackage -F Build-Depends libecal -or libebook gb.archive.ubuntu.com_ubuntu_dists_dapper*Sources
Package: contact-lookup-applet
Package: control-center
Package: deskbar-applet
Package: evolution-data-server
Package: evolution-exchange
Package: evolution-webcal
Package: gaim
Package: nautilus-sendto
Package: contacts
Package: glabels
Package: gnome-launch-box
Package: gnome-phone-manager
Package: hdate-applet
Package: revolution

No libraries, so the .la files can be stripped from e-d-s.

Ross
--
Ross Burton                                 mail: [hidden email]
                                          jabber: [hidden email]
                                     www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF


signature.asc (198 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: .la files

Loïc Minier
On Fri, May 05, 2006, Ross Burton wrote:
> $ grep-dctrl -sPackage -F Build-Depends libecal -or libebook gb.archive.ubuntu.com_ubuntu_dists_dapper*Sources

bee% grep-dctrl -sPackage -F Build-Depends evolution-data-server-dev <
/var/lib/apt/lists/*Sources
Package: evolution
Package: evolution-sharp
Package: gnomemeeting
Package: libopensync-plugin-evolution2
Package: multisync
Package: ximian-connector
Package: evolution
Package: evolution
Package: evolution-sharp
Package: gnomemeeting
Package: libopensync-plugin-evolution2
Package: multisync
Package: ximian-connector

 and:

bee% apt-cache rdepends libebook1.2-dev
libebook1.2-dev
Reverse Depends:
  libedataserverui1.2-dev
  libedata-book1.2-dev
  evolution-data-server-dev
  libedataserverui1.2-dev
  libedata-book1.2-dev
  evolution-data-server-dev

 etc.

--
Loïc Minier <[hidden email]>
"You can gtk_main_run, but you can't gtk_widget_hide." --danw, 19-jul-04


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: .la files

Ross Burton
On Fri, 2006-05-05 at 19:15 +0200, Loïc Minier wrote:

> On Fri, May 05, 2006, Ross Burton wrote:
> > $ grep-dctrl -sPackage -F Build-Depends libecal -or libebook gb.archive.ubuntu.com_ubuntu_dists_dapper*Sources
>
> bee% grep-dctrl -sPackage -F Build-Depends evolution-data-server-dev <
> /var/lib/apt/lists/*Sources
> Package: evolution
> Package: evolution-sharp
> Package: gnomemeeting
> Package: libopensync-plugin-evolution2
> Package: multisync
> Package: ximian-connector
> Package: evolution
> Package: evolution
> Package: evolution-sharp
> Package: gnomemeeting
> Package: libopensync-plugin-evolution2
> Package: multisync
> Package: ximian-connector

That's okay then: none of those are node libraries.

>  and:
>
> bee% apt-cache rdepends libebook1.2-dev
> libebook1.2-dev
> Reverse Depends:
>   libedataserverui1.2-dev
>   libedata-book1.2-dev
>   evolution-data-server-dev
>   libedataserverui1.2-dev
>   libedata-book1.2-dev
>   evolution-data-server-dev

All build from the same source tree, no problem.

Ross
--
Ross Burton                                 mail: [hidden email]
                                          jabber: [hidden email]
                                     www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF


Reply | Threaded
Open this post in threaded view
|

Re: .la files

Loïc Minier
On Fri, May 05, 2006, Ross Burton wrote:
> > bee% grep-dctrl -sPackage -F Build-Depends evolution-data-server-dev <
> That's okay then: none of those are node libraries.

 These are sources, so you need to check all binary packages of these
 sources.  I didn't check all of these sources, I was just saying that
 you can't just look at packages build-depending on libfoo-dev, you also
 have to look at packages which build-depend on something pulling
 libfoo-dev since dependency_libs= pulls all libs recursively.  Under
 these there's evolution-dev for example and it ships *.la files
 (perhaps that the only one shipping *.la files, and even if its *.la
 files reference libebook, you can ignore them as these are below
 /usr/lib/evolution/2.6, so the case of evolution-dev seems closed).

 Personally, I'm looking at the rdeps of -dev library, if there's no
 -dev rdep, or all rdeps don't have *.la files anymore, then it's ok to
 remove them, otherwise there was a missing dependency in the first
 place.

> > bee% apt-cache rdepends libebook1.2-dev
> All build from the same source tree, no problem.

 Same remark, I didn't check all of them, perhaps nothing in the rdeps
 has *.la files that depend on the *.la files from e-d-s-dev, but this
 has to be checked recursively (and this is what I usually check as
 explained above).

PS: please don't Cc: me, I read the list
--
Loïc Minier <[hidden email]>
"You can gtk_main_run, but you can't gtk_widget_hide." --danw, 19-jul-04


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: .la files

Ondřej Surý-4
> [...]
>  Personally, I'm looking at the rdeps of -dev library, if there's no
>  -dev rdep, or all rdeps don't have *.la files anymore, then it's ok to
>  remove them, otherwise there was a missing dependency in the first
>  place.
> [...]

Perhaps some of our excelent web-page-trackers developers could create
tracking tool which would check rdeps and .la files inside all binary
packages (or something like that)?

Ondrej.
--
Ondrej Sury <[hidden email]>

signature.asc (198 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: .la files

Ross Burton
In reply to this post by Loïc Minier
On Fri, 2006-05-05 at 20:44 +0200, Loïc Minier wrote:
> On Fri, May 05, 2006, Ross Burton wrote:
> > > bee% grep-dctrl -sPackage -F Build-Depends evolution-data-server-dev <
> > That's okay then: none of those are node libraries.
>
>  These are sources, so you need to check all binary packages of these
>  sources.

Good point.

Evolution would need a rebuild first.  Multisync should -- but I'm less
bothered about that as the opensync evo plugin directly build-deps. :)

Can our esteemed new Evolution maintainer agree to remove the .la files
from Evolution and Evolution Data Server shortly?

Ross
--
Ross Burton                                 mail: [hidden email]
                                          jabber: [hidden email]
                                     www: http://www.burtonini.com./
 PGP Fingerprint: 1A21 F5B0 D8D0 CFE3 81D4 E25A 2D09 E447 D0B4 33DF


Reply | Threaded
Open this post in threaded view
|

Re: .la files

"Øystein Gisnås"
lør, 06,.05.2006 kl. 07.08 +0100, skrev Ross Burton:
> Can our esteemed new Evolution maintainer agree to remove the .la files
> from Evolution and Evolution Data Server shortly?

Done in SVN.

-Øystein Gisnås

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: .la files

"Øystein Gisnås"
In reply to this post by Ross Burton
lør, 06,.05.2006 kl. 07.08 +0100, skrev Ross Burton:
> Can our esteemed new Evolution maintainer agree to remove the .la files
> from Evolution and Evolution Data Server shortly?

We have struggled a bit with a bug that was triggered by the removal
of .la from evolution. In the latest upload we put the .la files back in
while waiting for the real solution.

The symptoms can be seen when building something that depends on
evolution, for example evolution-exchange. Compile and linking succeed,
but the binaries that linked
against /usr/lib/evolution/2.6/libeutil.so.0.0.0
and /usr/lib/evolution/2.6/libevolution-addressbook-a11y.so.0.0.0 cannot
resolve those libraries, because RPATH is missing (can be seen with
objdump -p evolution-exchange-storage).

I have two questions. First, is it OK that another package links against
a library that is not in /usr/lib? Second, if the location of the libs
is OK, how can I make libtool put RPATH into evolution-exchange-storage
and other binaries linked against the two troublesome libraries? Is it a
bug in libtool, or must one set a flag to force RPATH in Makefile.am or
something?

I hope someone can help with this, so that the .la removal process can
continue.

Cheers,
--
Øystein Gisnås
Debian Evolution Maintainer Team

signature.asc (196 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: .la files

Josselin Mouette
Le lundi 12 juin 2006 à 18:37 +0200, Øystein Gisnås a écrit :

> The symptoms can be seen when building something that depends on
> evolution, for example evolution-exchange. Compile and linking succeed,
> but the binaries that linked
> against /usr/lib/evolution/2.6/libeutil.so.0.0.0
> and /usr/lib/evolution/2.6/libevolution-addressbook-a11y.so.0.0.0 cannot
> resolve those libraries, because RPATH is missing (can be seen with
> objdump -p evolution-exchange-storage).
>
> I have two questions. First, is it OK that another package links against
> a library that is not in /usr/lib?

I don't think it's a good idea, no.

> Second, if the location of the libs
> is OK, how can I make libtool put RPATH into evolution-exchange-storage
> and other binaries linked against the two troublesome libraries? Is it a
> bug in libtool, or must one set a flag to force RPATH in Makefile.am or
> something?

Another option is to put the libraries in /usr/lib and to use libtool's
-release flag, so that they are called libeutil-2.6.so.0.0.0 and so on.
Then, it makes sense to put them in a separate library package (like
libevolution-2.6-0).
--
 .''`.           Josselin Mouette        /\./\
: :' :           [hidden email]
`. `'                        [hidden email]
   `-  Debian GNU/Linux -- The power of freedom

Reply | Threaded
Open this post in threaded view
|

Re: .la files

"Øystein Gisnås"
tir, 13,.06.2006 kl. 16.55 +0200, skrev Josselin Mouette:

> Le lundi 12 juin 2006 à 18:37 +0200, Øystein Gisnås a écrit :
> > The symptoms can be seen when building something that depends on
> > evolution, for example evolution-exchange. Compile and linking succeed,
> > but the binaries that linked
> > against /usr/lib/evolution/2.6/libeutil.so.0.0.0
> > and /usr/lib/evolution/2.6/libevolution-addressbook-a11y.so.0.0.0 cannot
> > resolve those libraries, because RPATH is missing (can be seen with
> > objdump -p evolution-exchange-storage).
> >
> > I have two questions. First, is it OK that another package links against
> > a library that is not in /usr/lib?
>
> I don't think it's a good idea, no.
>
> > Second, if the location of the libs
> > is OK, how can I make libtool put RPATH into evolution-exchange-storage
> > and other binaries linked against the two troublesome libraries? Is it a
> > bug in libtool, or must one set a flag to force RPATH in Makefile.am or
> > something?
>
> Another option is to put the libraries in /usr/lib and to use libtool's
> -release flag, so that they are called libeutil-2.6.so.0.0.0 and so on.
> Then, it makes sense to put them in a separate library package (like
> libevolution-2.6-0).

The problem is then, of course, that upstream should be convinced to
reach a good long-term solution. There are 22 different libraries, and
something tell me it's gonna be a bit difficult.

As an interim solution I chose to explicitly tell each binary that links
against these libraries which RPATH to use. The good news is that .la
files then can be removed from evolution again.

My best suggestion for a long term solution is to pkg-config the private
libraries with "ldflags=-Wl,-R/usr/lib/evolution/2.6", and try to push
that through upstream.

-Øystein

Reply | Threaded
Open this post in threaded view
|

Re: .la files

Josselin Mouette
Le mardi 13 juin 2006 à 17:18 +0200, Oystein Gisnas a écrit :

> The problem is then, of course, that upstream should be convinced to
> reach a good long-term solution. There are 22 different libraries, and
> something tell me it's gonna be a bit difficult.
>
> As an interim solution I chose to explicitly tell each binary that links
> against these libraries which RPATH to use. The good news is that .la
> files then can be removed from evolution again.
>
> My best suggestion for a long term solution is to pkg-config the private
> libraries with "ldflags=-Wl,-R/usr/lib/evolution/2.6", and try to push
> that through upstream.
This is a good short term solution. Could it be applied to Debian?

The long term solution is to give correct version numbers to these
libraries and to move them to /usr/lib. There's no reason why it
couldn't be done.
--
 .''`.           Josselin Mouette        /\./\
: :' :           [hidden email]
`. `'                        [hidden email]
  `-  Debian GNU/Linux -- The power of freedom

signature.asc (196 bytes) Download Attachment