Makefile does not work on linux about kiss_fft HOT 22 CLOSED

Yep, the makefile needs some gussying up—it's pretty barebones.

The reason I haven't fixed it up is because I'm now installing it through homebrew (even on Linux).

If you've tapped my repo with brew tap benswift/extemporelinux then brew install kissfft should work. Let me know if it doesn't, since I've only tested on Ubuntu 13.10.

Cheers,
Ben

On 24/11/2013, at 1:50 PM, Andrew Sorensen [email protected] wrote:

compile options wrong for linux

—
Reply to this email directly or view it on GitHub.

from kiss_fft.

Odd. I wonder if Ubuntu has some special patches for GCC, since on Debian the problem is that -current_version is only available on Darwin, not Linux. I haven't tried homebrew on Linux, but the brew file seems to also use that option, not just the Makefile.

from kiss_fft.

Would replacing the shared target in the Makefile like this work:

gcc kiss_fft.c tools/kiss_fftr.c -fPIC -shared -I. -I/usr/include/malloc -o kiss_fft.1.3.0.so

That compiles for me and I'm able to load it, but I don't know exactly where to put it or what paths to change to get the entire compile process for extempore to work. I'd like to not depend on brew for this, I'm a fan of keeping my system as light as possible.

from kiss_fft.

Hi Gulshan

Yep, that will fix the makefile. Moving the lib into /usr/local/lib will put it on your path, although there should be an “install” target in the makefile which does that too. It really was just a hacked-together makefile for homebrew, I’ll look into cleaning it up at some stage if I have the time, but I’m pretty busy the next couple of weeks.

What problem are you having with installation? Where is it getting stuck?

Cheers,
Ben

On 15 Nov 2014, at 2:30 pm, Gulshan Singh [email protected] wrote:

Would replacing the shared target in the Makefile like this work:

gcc kiss_fft.c tools/kiss_fftr.c -fPIC -shared -I. -I/usr/include/malloc -o kiss_fft.1.3.0.so
That compiles for me and I'm able to load it, but I don't know exactly where to put it or what paths to change to get the entire compile process for extempore to work. I'd like to not depend on brew for this, I'm a fan of keeping my system as light as possible.

—
Reply to this email directly or view it on GitHub.

from kiss_fft.

I get the error:

Loading xtmfft library...
Error: could not load  kiss_fft.so  dynamic library
"Could not load kiss_fft dynamic library"

I have the shared library in the directory you specified:

$ ls /usr/local/lib/kiss_fft.so
/usr/local/lib/kiss_fft.so

from kiss_fft.

The problem might be that the old precompiled version (libs/fft.xtm) is getting in the way—perhaps try removing that (in fact it’s probably a good idea to clean everything with ./clean.bash first) and try recompiling the standard lib.

If that doesn’t work, what’s the state of your LD_LIBRARY_PATH environment variable?

Finally, you don’t need the fft library to do lots of things in Extempore, so you could just try building ./compile-stdlib-core.sh first (or even not precompiling the stdlib at all) just to get started. It depends on what you wanted to do (e.g. audio, graphics, etc.). What were you planning to do in Extempore?

Cheers,
Ben

On 17 Nov 2014, at 5:56 pm, Gulshan Singh [email protected] wrote:

I get the error:

Loading xtmfft library...
Error: could not load kiss_fft.so dynamic library
"Could not load kiss_fft dynamic library"
I have the shared library in the directory you specified:

$ ls /usr/local/lib/kiss_fft.so
/usr/local/lib/kiss_fft.so
—
Reply to this email directly or view it on GitHub.

from kiss_fft.

Tried to clean and then rebuild, but I get the same error. LD_LIBRARY_PATH is unset in my shell.

I wanted to import instruments_ext.xtm without it compiling everything every time. I've got the standard library to build fine, but I want to play around with other things in the external folder without waiting for them to compile.

And at this point, I'm also just curious why it's not working, and I like to fix things when they don't work.

from kiss_fft.

Tried to clean and then rebuild, but I get the same error. LD_LIBRARY_PATH is unset in my shell.

I wanted to import instruments_ext.xtm without it compiling everything every time. I've got the standard library to build fine, but I want to play around with other things in the external folder without waiting for them to compile.

And this point, I'm also just curious why it's not working, and I like to fix things when they don't work.

Sure, I understand. Unfortunately, I can’t think why it wouldn’t be working. One final question—are you building Extempore from GH master, or from the 0.58 tag?

—
Reply to this email directly or view it on GitHub.

from kiss_fft.

Sorry for the delayed reply, I had exams going on. I was building from master.

There's one final thing that might be worth noting. If I modify the following lines in src/external/fft.xtm:

(define libkissfft
  (sys:load-dylib (cdr *sys:precomp:current-load-dylib-info*)))

to be

(define libkissfft
  (sys:load-dylib "libs/kiss_fft.so"))

and put kiss_fft.so in the libs folder, the compile process actually gets passed compiling libs/external/fft.xtm. Specifically, this command now works: (sys:precomp:compile-xtm-file "libs/external/fft.xtm" #t #t #t)

However, the same kiss_fft.so occurs when compiling libs/external/audio_dsp_ext.xtm when it tries to load the xtmfft library. In other words, the precompiling works fine when I make that change, but I can't load the precompiled library after that. I guess that makes some sense, as a shared library is loaded at runtime, and it's possible that it can't find the shared library when it's loaded. I don't know if this information helps at all, I thought it might reveal something about why it can't seem to find this file.

from kiss_fft.

Hi Gulshan

It’s good that you’re using master—I pushed up some small fixes to the precomp stuff recently (about 2 weeks ago).

The sys:precomp:current-load-dylib-info variable is just a consed pair for keeping track of the current external lib when precompiling. This (in fact all the sys:precomp stuff) is necessary because each symbol should only exist in one precomped library, not all the precomped libraries for which that lib is loaded in the process. For example, the stuff in external/fft.xtm should only be included in precompilation of external/fft.xtm, not in external/audio_dsp.xtm.

There's one final thing that might be worth noting. If I modify the following lines in src/external/fft.xtm:

(define libkissfft
(sys:load-dylib (cdr sys:precomp:current-load-dylib-info)))
to be

(define libkissfft
(sys:load-dylib "libs/kiss_fft.so"))
and put kiss_fft.so in the libs folder, the compile process actually gets passed compiling libs/external/fft.xtm. Specifically, this command now works: (sys:precomp:compile-xtm-file "libs/external/fft.xtm" #t #t #t)

That’s interesting—the cdr of sys:precomp:current-load-dylib-info should be "libs/kiss_fft.so” at that point anyway. Can you print out the value of sys:precomp:current-load-dylib-info just before the (define libkissfft … line for me?

Cheers,
Ben

On 7 Dec 2014, at 3:52 pm, Gulshan Singh [email protected] wrote:

Sorry for the delayed reply, I had exams going on. I was building from master.

However, the same kiss_fft.so occurs when compiling libs/external/audio_dsp_ext.xtm when it tries to load the xtmfft library. In other words, the precompiling works fine when I make that change, but I can't load the precompiled library after that. I guess that makes some sense, as a shared library is loaded at runtime, and it's possible that it can't find the shared library when it's loaded. I don't know if this information helps at all, I thought it might reveal something about why it can't seem to find this file.

—
Reply to this email directly or view it on GitHub.

from kiss_fft.

This is what I get when I print it out: (libkissfft . kiss_fft.so)

from kiss_fft.

Hmm, that’s weird. The cdr of that pair should be a string, not a symbol. So it should print as (libkissfft . “kiss_fft.so”) - note the quotation marks.

That gets set just above, in the cond statement (line 34). Can you see what it should be set to? What’s the output of (sys:platform) ?

Cheers,
Ben

On 8 Dec 2014, at 4:21 pm, Gulshan Singh [email protected] wrote:

This is what I get when I print it out: (libkissfft . kiss_fft.so)

—
Reply to this email directly or view it on GitHub.

from kiss_fft.

I printed it out and I got Linux, which corresponds to

...
((string=? (sys:platform) "Linux")
 "kiss_fft.so")
...

I don't know enough about Lisp to figure out how the string got converted to a symbol. Maybe there's some bug in sys:precomp:set-dylib-name-info? I can't find the source for it.

from kiss_fft.

I don't know enough about Lisp how the string got converted to a symbol. Maybe there's some bug in sys:precomp:set-dylib-name-info? I can't find the source for it.

That function is incredibly simple: it just sets a global (defined in runtime/scheme.xtm:1266)

(define sys:precomp:set-dylib-name-info
  (lambda (symbol-name dylib-path)
    ;; is there a better way to check if a file exists?
    (set! *sys:precomp:current-load-dylib-info*
          (cons symbol-name dylib-path))))

I’m not 100% sure it’s being converted to a symbol—it depends how you were printing it (println will keep the quotes, print will lose them).

As a final, check-for-certain effort, try calling this before the sys:load-dylib call

(if (string? (cdr *sys:precomp:current-load-dylib-info*))
    (println "it's a string")
    (println "whoops, it's not a string - something's gone wrong"))

If it’s a string, then we’ll have to go spelunking into the C++ source I’m afraid :(

—
Reply to this email directly or view it on GitHub.

from kiss_fft.

Shoot. I was using print. println shows the quotes.

Your code prints "it's a string". On to the C++ source!

from kiss_fft.

But why would setting that variable to libs/kiss_fft.so let it find the file (at least when it's compiling), but when it's set to only kiss_fft.so, it wouldn't find the file?

from kiss_fft.

Just had some head-scratching getting this working on Linux Fedora 21.

• kiss_fft is not mentioned as a dependency on the linux build guide, or the README. I realized it's missing when the stdlib compilation failed, and found the repo by digging through the source code.
• The makefile doesn't work for linux as @gsingh93 has stated. The following targets worked:

shared:
        gcc kiss_fft.c tools/kiss_fftr.c -fPIC -shared  -I. -o kiss_fft.1.3.0.so

install: shared
        mv kiss_fft.1.3.0.so /TheTargetDir/kiss_fft.so

• The default name used by the install is not a proper soname which must begin with 'lib'. dlopen(3) looks specifically for files by name in /lib (fallback described in manpage) which works, but if you put it anywhere else on the search path it won't be picked up unless it has a 'lib' prefix as it should.
• At least on fedora /usr/local/lib{64} is not part of the default search path while /lib{64} -> /usr/lib{64} are, see manpage for dlopen(3). See SO question on how to add directories to the ldconfig search path.

The Hacky fix:

• Clone repo.
• sudo gcc kiss_fft.c tools/kiss_fftr.c -fPIC -shared -I. -o /lib64/kiss_fft.so.
• Go.

The proper fix:

• Rename lib to libkiss_fft.so in makefile and fft.xtm.
• Install to /lib{64} or whatever is on every distro's ldconfig search path. Dunno about Debian/Ubuntu.
• Add linux makefile or add portability logic to existing file.
• Update build guide mentioning the dep and pointing to the repo (or use git submodules)

On top of patching and compiling llvm it's been quite a chore to get up and running.

from kiss_fft.

Thanks @giorashh! Your instructions finally helped me compile fft.xtm. Just one note, your instructions say the shared library must start with lib, but your gcc commands don't output a file starting with lib. I had to manually rename it. Is this a typo or was this intended?

Now that the fft.xtm files has properly compiled, I'm getting "Could not load librtmidi dynamic library". I should be able to install all the missing dependencies (looks like this shared library is provided by rtmidi on archlinux), but it would be nice to have all the dependencies listed in one place.

from kiss_fft.

We could also submit a pull request with the Makefile fixes to make this easier for @benswift.

from kiss_fft.

@gsingh93, if you put the .so in /lib specifially, extempore will find it despite the missing 'lib' prefix.

I can put up a PR if there's a verdict on changing the filename. @benswift?

from kiss_fft.

ping @benswift

from kiss_fft.

yeah, we probably should change this to rtmidic or crtmidi or something - it's not good form to clash with the existing .so. @digego do you have any preference?

from kiss_fft.