#musicbrainz

no that's not a problem

i'm enough C/C++ literate myself to fix that

what i mean is this:

luks: http://rafb.net/paste/results/8Z3JOz55.html

i'm trying to find out why this happens

hmm!

i guess they link libfftw statically AND dynamically

at least that's how it looks like

i've never seen this before

well they for sure do link it dynamically

luks: well and i assure you before we get into discussions that i must be doing something odd that i don't :P

(just a precaution :P)

they link against -lfftw3

tw3

and then they have:

yep, but why statically? :)

well AFLIB

luks: no idea

cause they're closed source people

they always develop like that

it links dynamically to fttw3 on here

-on

I had that problem on macosx.

luks:

AFLIB/.libs/libaflib.a(align.o):align.c:(.text+0x0): first defined here

I remcompiled fttw3 dynamic only.

yeah that's what i was about to do

but i first wanted to find out what the reason/bug is in their buildsystem

well, i think it's a problem with your setup

ahem

look what tru just said

it might be, "of course" a problem with both our setups >_>

"sure" o_O

no, i mean, do you want to link to fftw3 statically or dynamically?

well i'm trying to find the reason and submit them a patch

luks: it's not the point what _i_ want

that thing should not try to link boht

both*

well, it uses -lfftw3

yeah and somehow it also links to libfftw3.a

it's obvious

look at what i pasted above

luks: really i'm coding and buildsystem (at least autotools) and gcc/g++ literate enough to tell you that this is what this thing is trying to do

ah, i see

and i'm trying to find out why

well, this looks more like a libtool problem

it could be, though, a libfftw3 bug

it passes -lfftw3 to libtool

and libtool uses /usr/lib/libfftw3.a

but

luks: that would be no problem

if it wouldn't at the same time to link the solib as well

(or .dylib on osx then)

yeah i have it only built statically

i actually thought up to now that libfftw3 exists in both forms

so, the problem is, it doesn't know that it links it statically

basically, sort of, you're right

but they need to either:

stupid question, but do you have installed the dynamic lib?

- check for fftw3 being present as a dynamically linkable lib, and otherwise not build libofa

or

- adjust their buildsystem to link properly against libfftw3 as a static lib

luks: no i haven't but that is not the point

you see you're going to tell me

<luks> well, that is the problme

em*

but it's not

well in the _end_, right now, it is the problem

ideally it should link to static version as well, but obviously it doesn't

but the general problem is that their build system is erroneus

but i don't think that's libofa bug

yeah

sure it is

how?

-lblah doesn't specify whether it should be a dynamically linkable lib or a static lib

their build system needs to check for the presence of the dynamic libfftw3

what if i have a static fftw3 (that actually works) and want to it?

they can do that very easily with

AC_CHECK_LIB()

i think

since nm -D will not work with a static lib

Hmm. A quick question: shouldn't singles be (generally) named after their main track?

let's see

so you are saying that the build system should disallow linking to static version, right?

hmmm ok AC_CHECK_LIB does not use nm or anything

as the check passes

luks: either that, or it should accomodate for linking against the static version

srotta: yes, usually

I'm seeing quite many singles that have both A and B side in the release title.

right now, it is unaware that the lib might be present as a static lib

but what if i *want* link to the static version?

then you have to specify --with-fftw3-static to libofa's configure

which currently does not exist but they must add it

look i don't code since 3 days ago ok? :P

well, if you have installed both versions libtool will prefer the dynamic one. if you have only the dynamic one, libtool will use it. if you have *correct* static lib, libtool will use it

where's the problem?

the only problem is if you have broken static version

i pasted you the problem

i don't understand why you don't see that libofa is just broken atm

?

can you link anything agains that static lib?

what is the problem in seeing that?

are you basically saying that i _must_ have the dynamic lib installed in order to build libofa

and if i _don't_ have it

?

but what i _want_ to use the static lib

mudcrow: I also find it annoying, that for some reason there are several vinyl singles that are categorized as EP's :P

is that your statement?

?

luks: ^

luks: ^

you get the error because your libfftw3 install it broken

there are a few other apps that i know of that allow of linking to another lib dynamically or statically and they are _aware_ of the fact that this other lib can come in both forms

and they all have a switch lib --with-somelib-static

and they do prefer the dynamic version usually, some do it the other way round

srotta: a lot of singles are a mess, listed as all sorts of things.

but this is nothing unusual, and not weird and a "bad idea" in any way

luks: lol?

luks: how is it broken?

i simply did not specify to build the dynamic lib

can you link *anything* to that fftw3?

that does not qualify as broken

luks: even if i can't it does not qualify as broken if it's an option to build fftw3 like that

why should it require you to use the dynamic link?

*lin

bleh!

dynamic lib

luks:

[mderezynski [at core] ~]$

sure i can link something else against it

not mine, not libfftw3, or anything else

Whee! Almost done with the composers on Rubai! :D

deadchip: you don't use any fftw3 code there

luks: that doesn't matter

luks: if you are familiar with linking

luks: then you should know that this doesn't matter

echo 'int main() { fftw_alignment_of();}' > test.c && gcc test.c -lfftw3

i can illustrate you their problem like this:

luks:

wait

no no

here:

[mderezynski [at core] fftw]$ cat tu1.c

[mderezynski [at core] fftw]$

now:

[mderezynski [at core] fftw]$ cat tu2.c