Re: [LAU] jackdmp and libjack.la (was: Jackbeat 0.7)

From: Stéphane Letz <letz@email-addr-hidden>
Date: Mon May 11 2009 - 17:06:27 EEST

Le 11 mai 09 à 15:27, Olivier Guilyardi a écrit :

> Stéphane Letz wrote:
>>
>> Le 11 mai 09 à 14:43, Olivier Guilyardi a écrit :
>>
>>> Dave Phillips wrote:
>>>> 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
>>
>>
>> What is the libjack.la file supposed to contain? and what is it for?
>
> .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

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
_______________________________________________
Linux-audio-user mailing list
Linux-audio-user@email-addr-hidden
http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user
Received on Mon May 11 20:15:02 2009

This archive was generated by hypermail 2.1.8 : Mon May 11 2009 - 20:15:02 EEST