-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Some time ago there was a long thread regarding libtool files which started with why dia has .la files.
I was unable to respond to that thread since i was travelling at that time. In the mean time it seems that someone removed the .la files from dia according to the fedora packaging policy.
However now dia crashes with an error message, i have done some preliminary investigation ( Ref BZ 475992 ) and it seems that the source is looking at the la files to determine the libs.
I am going to talk to upstream to see if this behaviour can be changed. However my question is in case they dis-agree what are the options do we have?
Do we bring the .la files back so that dia works ? - -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas)
GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5
Huzaifa Sidhpurwala wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Some time ago there was a long thread regarding libtool files which started with why dia has .la files.
I was unable to respond to that thread since i was travelling at that time. In the mean time it seems that someone removed the .la files from dia according to the fedora packaging policy.
However now dia crashes with an error message, i have done some preliminary investigation ( Ref BZ 475992 ) and it seems that the source is looking at the la files to determine the libs.
I am going to talk to upstream to see if this behaviour can be changed. However my question is in case they dis-agree what are the options do we have?
Do we bring the .la files back so that dia works ?
tough choice... what should we select, a working application with .la files included, or a nicely-packaged-but-crashing app ?
Manuel Wolfshant píše v So 03. 01. 2009 v 16:39 +0200:
Huzaifa Sidhpurwala wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Some time ago there was a long thread regarding libtool files which started with why dia has .la files.
I was unable to respond to that thread since i was travelling at that time. In the mean time it seems that someone removed the .la files from dia according to the fedora packaging policy.
However now dia crashes with an error message, i have done some preliminary investigation ( Ref BZ 475992 ) and it seems that the source is looking at the la files to determine the libs.
I am going to talk to upstream to see if this behaviour can be changed. However my question is in case they dis-agree what are the options do we have?
Do we bring the .la files back so that dia works ?
tough choice... what should we select, a working application with .la files included, or a nicely-packaged-but-crashing app ?
IMHO a working application is always preferred :-) But the plugin loading mechanism can be checked why it requires the *.la files.
Dan
Dan Horák wrote:
IMHO a working application is always preferred :-) But the plugin loading mechanism can be checked why it requires the *.la files.
+1. The problematic .la files that should be avoided are those associated with (linkable) shlibs. Plugin .la files are mostly harmless.
-- Rex
Rex Dieter wrote:
Dan Horák wrote:
IMHO a working application is always preferred :-) But the plugin loading mechanism can be checked why it requires the *.la files.
The only time I've seen .la files really being needed was with KDE-3. And that wasn't so much an issue that couldn't be solved as the KDE sig wanting to put effort into KDE-4 rather than working on the deficincies in KDE-3.
+1. The problematic .la files that should be avoided are those associated with (linkable) shlibs. Plugin .la files are mostly harmless.
I thought Michael Schwendt pointed out times when plugin .la's would cause issues as well. Is this chain of reasoning correct: Plugin .la encodes need for library foo's .la. foo .la is packaged in the -devel subpackage. Plugins now drag in the -devel package and its dep chain.
-Toshio
Toshio Kuratomi wrote:
I thought Michael Schwendt pointed out times when plugin .la's would cause issues as well. Is this chain of reasoning correct: Plugin .la encodes need for library foo's .la. foo .la is packaged in the -devel subpackage. Plugins now drag in the -devel package and its dep chain.
Could be, but afaik missing .la items haven't caused runtime problems afaik (as long as symbols are otherwise resolvable), but that would change when/if rpm's automatic .la file dependencies were ever used.
So, yeah, still a good general idea (per guidelines) to avoid the hassle whenever possible.
-- Rex
On Sat, 2009-01-03 at 16:07 +0100, Dan Horák wrote:
Manuel Wolfshant píše v So 03. 01. 2009 v 16:39 +0200:
Huzaifa Sidhpurwala wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Some time ago there was a long thread regarding libtool files which started with why dia has .la files.
I was unable to respond to that thread since i was travelling at that time. In the mean time it seems that someone removed the .la files from dia according to the fedora packaging policy.
However now dia crashes with an error message, i have done some preliminary investigation ( Ref BZ 475992 ) and it seems that the source is looking at the la files to determine the libs.
I am going to talk to upstream to see if this behaviour can be changed. However my question is in case they dis-agree what are the options do we have?
Do we bring the .la files back so that dia works ?
tough choice... what should we select, a working application with .la files included, or a nicely-packaged-but-crashing app ?
IMHO a working application is always preferred :-) But the plugin loading mechanism can be checked why it requires the *.la files.
There is no deep reason why dias plugin support looks for .la files. It would be a 3 line patch to make it look for .so instead.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Matthias Clasen wrote:
On Sat, 2009-01-03 at 16:07 +0100, Dan Horák wrote:
Manuel Wolfshant píše v So 03. 01. 2009 v 16:39 +0200:
Huzaifa Sidhpurwala wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Some time ago there was a long thread regarding libtool files which started with why dia has .la files.
I was unable to respond to that thread since i was travelling at that time. In the mean time it seems that someone removed the .la files from dia according to the fedora packaging policy.
However now dia crashes with an error message, i have done some preliminary investigation ( Ref BZ 475992 ) and it seems that the source is looking at the la files to determine the libs.
I am going to talk to upstream to see if this behaviour can be changed. However my question is in case they dis-agree what are the options do we have?
Do we bring the .la files back so that dia works ?
tough choice... what should we select, a working application with .la files included, or a nicely-packaged-but-crashing app ?
IMHO a working application is always preferred :-) But the plugin loading mechanism can be checked why it requires the *.la files.
There is no deep reason why dias plugin support looks for .la files. It would be a 3 line patch to make it look for .so instead.
Matthias, I saw your comment on the bugzilla, I am going to apply that patch and see if that works, Thanks a lot.
- -- Regards, Huzaifa Sidhpurwala, RHCE, CCNA (IRC: huzaifas)
GnuPG Fingerprint: 3A0F DAFB 9279 02ED 273B FFE9 CC70 DCF2 DA5B DAE5
devel@lists.stg.fedoraproject.org
-
Dan Horák -
Huzaifa Sidhpurwala -
Manuel Wolfshant -
Matthias Clasen -
Rex Dieter -
Toshio Kuratomi