linuxaudio.org

Le 11 mai 09 à 15:27, Olivier Guilyardi a écrit :
> Stéphane Letz wrote:

quoted text
>>

>> 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@lists.linuxaudio.org

http://lists.linuxaudio.org/mailman/listinfo/linux-audio-user