11 May
2009
11 May
'09
11:27 a.m.
Stéphane Letz wrote:
Le 11 mai 09 à 14:43, Olivier Guilyardi a écrit :
.la files are files generated and used by libtool to link a shared library with
another library. These files actually contains a small amount of textual
meta-data for libtool to decide how linking should be performed. They do not
replace .so or .a files, they complement them in the libtool world.
In other terms, every autoconf/automake based software which builds a shared
library which is itself linked with libjack, normally uses libtool and thus
requires libjack.la to be present. This includes applications (such as Muse I
presume) which build convenient internal shared libraries.
I suggest that you ask on the waf-users google group how to make an .la file,
they know what this is all about.
--
Olivier
Dave Phillips wrote:
What is the libjack.la file supposed to contain? and what is it for? On Sun, 2009-05-10 at 22:45 +0200, Olivier
Guilyardi wrote:
Glad to read that :) Thanks for your feedback.
Okay, this problem should be solved in SVN.
And so it is, thank you. :)
> To a certain extent one might consider the problem comes from the
> jackdmp waf
> build system, which doesn't provide libtool .la files, while all
> packaged
> libraries do provide these files.
[...]
I've run into the same problem when trying to
build the latest MusE 1.0
rc2. It gets to the link stage and fails because of missing libjack.la.
If anyone from the MusE development group reads this perhaps they too
can reconsider their use of libtool.
Well, every single autoconf/automake-based software which builds a shared
library for internal or external use, normally uses libtool. Thus, I
think that
the fact that jackdmp doesn't provide libjack.la is a bug.
I'm CC'ing Stéphane Letz. Although I don't know how to do it, I
suppose that you
can make .la files with waf, since it claim(ed) to support libtool
emulation.
--
Olivier 
11 May
11 May
12:10 p.m.
New subject: jackdmp and libjack.la (was: Jackbeat 0.7)
Le 11 mai 09 à 15:27, Olivier Guilyardi a écrit :
Stéphane Letz wrote:
It seems using .la file is *bad idea* AKAIKS, see:
Jun 09 21:03:51 * drobilla wonders if he can emulate his recursive but
separate build system thingie w/ waf
Jun 09 21:03:51 nedko drobilla: yup, versioning is very easy but i
havent tried generation of .la files yet
Jun 09 21:04:05 las nedko: DON'T !!!!!!!!
Jun 09 21:04:08 moret drobilla: just for info, if you want to test
netjack2, please use waf, it's better than scons for netjack...
Jun 09 21:04:09 drobilla meh, who needs 'em
Jun 09 21:04:12 las .la files are the devil's work
Jun 09 21:04:22 nedko las: dont what?
Jun 09 21:04:32 drobilla moret: obviously I did use waf ;)
Jun 09 21:04:32 las nedko: don't try to generate .la files
Jun 09 21:04:41 drobilla moret: don't plan on testing netjack, but
thanks
Jun 09 21:05:02 nedko las: i havent, but autotools do it, and i think
waf can do that too
Jun 09 21:05:31 drobilla las: you do know the way libraries are built
in the ardour tree is completely inappropriate for distribution
right? :)
Jun 09 21:05:43 drobilla (not because of .la files, but still. life
is less fun when it's not just a helper)
Jun 09 21:05:54 las drobilla: depends who you talk to. Mozilla still
does it this way
Jun 09 21:06:05 las drobilla: and they have a pretty solid rationale
for it
Jun 09 21:06:32 drobilla las: you can't system wide install completely
unversioned shared libraries!
Jun 09 21:06:56 drobilla no way they do. maybe in version specific /
lib/mozilla
Jun 09 21:07:39 las drobilla: they are not installed system wide,
never ever
Jun 09 21:07:52 drobilla las: ok, well that doesn't count :)
Jun 09 21:07:58 las drobilla: yes it bloody well does
Jun 09 21:08:05 drobilla .... not really
Jun 09 21:08:13 drobilla as far as build tools being usable for
libraries anyway
Jun 09 21:08:34 drobilla though you just have to append a bunch of
flags, it's not that bad
Jun 09 21:08:41 nedko the buffered stdout issue is getting really
complex, i wonder whether we should force lash programs to disable
stdout buffereing or we should use unbuffer trick or something like that
Jun 09 21:08:50 drobilla says a lot about where scons is coming from
though ;)
Jun 09 21:09:15 drobilla ie windows style "fuck it we'll just build
everything we need locally, libraries are stupid" land
Jun 09 21:09:18 las drobilla: sure, it does say that
Jun 09 21:09:29 las drobilla: but it doesn't say anything about ardour
packaging
Jun 09 21:10:01 drobilla las: I mean that way of building isn't
suitable for distribution if it was building a library normally
Jun 09 21:10:07 drobilla las: obviously for helpers it doesn't matter
whatsoever
Jun 09 21:10:29 drobilla I find it a bit retarded to pitch a next gen
build system that can't even easily be used for shared library projects
Jun 09 21:10:41 las nedko: but the whole point of .la files is ....
busted
Jun 09 21:10:54 las nedko: it exists to address a problem that doesn't
exist on any interesting platform
Jun 09 21:11:05 drobilla does anything remotely relevant even use
those anymore anyway?
Jun 09 21:11:19 las drobilla: libtool still does
Jun 09 21:11:19 nedko las: i'm in no way fan of .la files, i dont even
know how they really work
Jun 09 21:11:46 las nedko: they exist because once there were some
platforms where a shared library didn't contain enough information to
do "good" run time linking
Jun 09 21:11:47 drobilla las: are they required to link against a
shared lib with libtool at all?
Jun 09 21:12:03 las nedko: this pretty much came to an end at least 5
years ago, maybe more
Jun 09 21:12:07 * drobilla thinks not
Jun 09 21:12:08 las drobilla: no, they are not
Jun 09 21:12:21 drobilla eff 'em then :)
Jun 09 21:12:35 drobilla perhaps still useful for system installed
static libs?
Jun 09 21:12:48 las drobilla: they are of no use for static libs at
all, AFAIK
Jun 09 21:12:51 nedko so devil's work is void since 5 years?
Jun 09 21:12:52 nedko :D
Jun 09 21:13:01 drobilla las: dependencies?
Jun 09 21:13:20 las nedko: something like that. if you still want to
build for Irix from 8 years ago, then "Rock On libtool!"
Jun 09 21:13:29 las drobilla: inferrable on every platform worth
caring about
Jun 09 21:13:53 las drobilla: they have to be because otehrwise static
linking wouldn't work
Jun 09 21:14:29 drobilla las: I don't think dependency information is
in static libs
Jun 09 21:14:33 drobilla las: could be wrong
Jun 09 21:14:57 drobilla las: 'course this all carries the obvious
disclaimer of: who actually installs/uses system wise static libs? :)
Jun 09 21:15:05 nedko irix should be dead because sgi is dead, no?
Jun 09 21:15:30 nedko althrough i used irix system 2 or 3 years ago
Jun 09 21:15:37 drobilla if it isn't BSD or linux, it's dead :)
Jun 09 21:15:58 nedko drobilla: macos is not bsd at all ;)
Jun 09 21:16:17 drobilla or that
So woul'nt be better to solve the initial issue at the right place?
Stephane
Le 11 mai 09 à 14:43, Olivier Guilyardi a écrit :
.la files are files generated and used by libtool to link a shared
library with
another library. These files actually contains a small amount of
textual
meta-data for libtool to decide how linking should be performed.
They do not
replace .so or .a files, they complement them in the libtool world.
In other terms, every autoconf/automake based software which builds
a shared
library which is itself linked with libjack, normally uses libtool
and thus
requires libjack.la to be present. This includes applications (such
as Muse I
presume) which build convenient internal shared libraries.
I suggest that you ask on the waf-users google group how to make
an .la file,
they know what this is all about.
--
Olivier Dave Phillips wrote:
What is the libjack.la file supposed to contain? and what is it for? On Sun, 2009-05-10 at 22:45 +0200, Olivier
Guilyardi wrote:
> Okay, this problem should be solved in SVN.
>
And so it is, thank you. :)
Glad to read that :) Thanks for your feedback.
> To a certain extent one might consider the problem comes from the
> jackdmp waf
> build system, which doesn't provide libtool .la files, while all
> packaged
> libraries do provide these files.
[...]
I've run into the same problem when trying to
build the latest
MusE 1.0
rc2. It gets to the link stage and fails because of missing
libjack.la.
If anyone from the MusE development group reads this perhaps they
too
can reconsider their use of libtool.
Well, every single autoconf/automake-based software which builds a
shared
library for internal or external use, normally uses libtool. Thus, I
think that
the fact that jackdmp doesn't provide libjack.la is a bug.
I'm CC'ing Stéphane Letz. Although I don't know how to do it, I
suppose that you
can make .la files with waf, since it claim(ed) to support libtool
emulation.
--
Olivier
12:44 p.m.
New subject: jackdmp and libjack.la
Stéphane Letz wrote:
[...]
I know there's a controversy about .la files. libtool is certainly a very old
thing, and I don't like it either.
But, you should consider the fact that Debian, Ubuntu, Fedora, etc.. include .la
files for all libs, and ask yourself whether you want to maximize compatibility
with Muse and others.
And what you really should do IMO is ask on waf-users. These guys know the
problem and will tell you what's best.
--
Olivier
In other
terms, every autoconf/automake based software which builds a
shared
library which is itself linked with libjack, normally uses libtool and
thus
requires libjack.la to be present. This includes applications (such as
Muse I
presume) which build convenient internal shared libraries.
I suggest that you ask on the waf-users google group how to make an
.la file,
they know what this is all about.
It seems using .la file is *bad idea* AKAIKS, see: 
1:28 p.m.
New subject: jackdmp and libjack.la
Il giorno Mon, 11 May 2009 16:44:35 +0200
Olivier Guilyardi <ml(a)xung.org> ha scritto:
Stéphane Letz wrote:
[...]
I know there's a controversy about .la files. libtool is certainly a
very old thing, and I don't like it either.
But, you should consider the fact that Debian, Ubuntu, Fedora, etc..
include .la files for all libs, and ask yourself whether you want to
maximize compatibility with Muse and others.
jack package for debian testing doesn't include .la files anymore;
luigi@pozzaibe:~$ apt-file list libjack-dev
libjack-dev: /usr/include/jack/intclient.h
libjack-dev: /usr/include/jack/jack.h
libjack-dev: /usr/include/jack/midiport.h
libjack-dev: /usr/include/jack/ringbuffer.h
libjack-dev: /usr/include/jack/statistics.h
libjack-dev: /usr/include/jack/thread.h
libjack-dev: /usr/include/jack/timestamps.h
libjack-dev: /usr/include/jack/transport.h
libjack-dev: /usr/include/jack/types.h
libjack-dev: /usr/lib/libjack.a
libjack-dev: /usr/lib/libjack.so
libjack-dev: /usr/lib/libjackserver.a
libjack-dev: /usr/lib/libjackserver.so
libjack-dev: /usr/lib/pkgconfig/jack.pc
it changed in this version:
jack-audio-connection-kit (0.116.1-3) unstable; urgency=low
* Don't install *.la files in libjack-dev. (Closes: #510673)
* Add myself to Uploaders
this is the bug:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=%23510673
ciao
Luigi
--
~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
Io sono
lo sbaglio, il momento di confusione, l'inopportuno
Non sono niente.
Non sarò mai niente.
Non posso volere d'essere niente.
A parte questo, ho in me tutti i sogni del mondo.
F. Pessoa
~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*~*
In other
terms, every autoconf/automake based software which
builds a shared
library which is itself linked with libjack, normally uses libtool
and thus
requires libjack.la to be present. This includes applications
(such as Muse I
presume) which build convenient internal shared libraries.
I suggest that you ask on the waf-users google group how to make an
.la file,
they know what this is all about.
It seems using .la file is *bad idea* AKAIKS, see: 
12:50 p.m.
New subject: jackdmp and libjack.la
Stéphane Letz wrote:
[snip]
So woul'nt be better to solve the initial issue at the right place?
I read the IRC log, but I'm not sure which place is the right one. Waf ?
Jackdmp's sources ? The distro ?
Beyond my immediate problem of building the latest MusE, I wondered how
all this stuff will be handled in the very near future, i.e. how is 64
Studio 3 going to build MusE if its build system demands libjack.la and
the distro hasn't yet bumped up to jackdmp ? And if jackdmp's waf build
manager doesn't make .la files how will 64 Studio accommodate Jackbeat,
MusE, and others after bumping up ?
Olivier, was there any special difficulty in removing the libtool stuff
from Jackbeat's build system ? If it's a relatively painless procedure
I'll try to remove the dependency from MusE's sources to see if I can
get it completely built here.
Best,
dp
1:14 p.m.
New subject: jackdmp and libjack.la
Dave Phillips wrote:
Stéphane Letz wrote:
<jackdmp>/linux/wscript should be the place where to say that you want to
generate libjack.la.
[snip]
So woul'nt be better to solve the initial issue at the right place?
I read the IRC log, but I'm not sure which place is the right one. Waf ?
Jackdmp's sources ? The distro ?
Beyond my immediate problem of building the latest MusE, I wondered how
all this stuff will be handled in the very near future, i.e. how is 64
Studio 3 going to build MusE if its build system demands libjack.la and
the distro hasn't yet bumped up to jackdmp ? And if jackdmp's waf build
manager doesn't make .la files how will 64 Studio accommodate Jackbeat,
MusE, and others after bumping up ?
Olivier, was there any special difficulty in removing the libtool stuff
from Jackbeat's build system ? If it's a relatively painless procedure
I'll try to remove the dependency from MusE's sources to see if I can
get it completely built here.
I don't know the MusE code, and I can't tell you how difficult that would be,
and even if this is really recommendable or possible. In Jackbeat it was very
easy, but it may be *very* different in MusE. I presume it builds some shared
library for its own use, where some low level stuff is well encapsulated, and
which is linked to libjack.
In order to remove libtool you would need to build this internal MusE lib as a
static library. I just hope this shared library isn't (meant to be) used by
another app than MusE, because then you obviously shouldn't build it as a static
lib...
If that can help, here's the way I turned the offending Jackbeat's libstream
into a static library:
http://jackbeat.samalyse.org/changeset?new=570%40trunk&old=567%40trunk
--
Olivier
5677
days inactive
5677
days old
linux-audio-user@lists.linuxaudio.org
6 comments
4 participants
participants (4)
-
Dave Phillips -
luigi curzi -
Olivier Guilyardi -
Stéphane Letz