search

CICM / pd-faustgen

The FAUST compiler embedded in a Pd external
MIT License
43 stars 7 forks source link

On archlinux faustgen~ kills pd on startup #7

Closed g2oo7fy closed 5 years ago

g2oo7fy commented 5 years ago

running

pd -path /usr/lib/pd/extra/faustgen -lib faustgen~

will produce this error:

: CommandLine Error: Option 'disable-symbolication' registered more than once!
LLVM ERROR: inconsistency in registered CommandLine options

My systems packages versions are this:

Do they interfere with the submodules?

g2oo7fy commented 5 years ago

I also have purr-data installed:

After calling purr-data -path /usr/lib/pd/extra/faustgen -lib faustgen~ the same thing happens as with pd.

g2oo7fy commented 5 years ago

Removing the systems installations of faust and llvm also doesn't change anything.

pierreguillot commented 5 years ago

I thinks this is related to this issue. There is a conflict between a static library (that should be on your system) and a dynamic library that is "embedded" in faustgen~. Both must have been linked with faustgen~ and when the object is loaded, the object load the symbol twice. The solution would be to remove the dynamic library from LLVM_LIBS (I think this is the last LLVM symbol).

Did you compiled faustgen~ or did you use the pre-build binaries ?

pierreguillot commented 5 years ago

@g2oo7fy ?

g2oo7fy commented 5 years ago

Sorry for the late reply! The error was with the selfcompiled faustgen~ and it works fine with the pre-build binaries. Do I understand it right, that as soon as we achieve to compile faustgen with dynamically linked libraries, faustgen could even be run alongside @agraef 's pd-pure?

pierreguillot commented 5 years ago

Normally, you should already be able to load both libraries (faust~ and faustgen~). Because, faust~ uses the dynamic library on your system and faustgen~ uses the static library embedded in the external. Did you already tried the pre-build faustgen~ with faust~? You can also try to compile faustgen~ with the dynamic faust library, I think you only have to change these lines in FaustLib.cmake: https://github.com/CICM/pd-faustgen/blob/master/FaustLib.cmake#L21.

agraef commented 5 years ago

Hi @g2oo7fy, just to clarify, the issue certainly isn't with libfaust which faust~ doesn't use at all in the current implementation, but with LLVM which has some global data structures wreaking havoc if more than one compiler uses LLVM as its backend in the same program. So you have to avoid using two externals using the same shared instance of the LLVM libraries. Trying to run pd-pure along with the csound~ external with Faust opcodes causes similar crashes.

As Pierre has pointed out, and your previous comment seems to confirm, this might work if libfaust is linked to LLVM statically. I've never tried that myself, though. But if both are linked against the shared LLVM library, it won't work, and probably never will.

Forgive my curiousity, but is there a reason why you'd want run both? Is there any feature in faustgen~ which you need and faust~ lacks right now, or vice versa?

agraef commented 5 years ago

Just for the record, I gave it a whirl myself now, but for me faustgen~ crashes as soon as I have pd-pure loaded in Pd:

$ pd -lib pure faustgen~-help.pd 
Segmentation fault (core dumped)

I have faustgen~ installed from Deken, and AFAICT there's no external dependency on libfaust or the LLVM libraries:

$ ldd faustgen~.pd_linux 
        linux-vdso.so.1 (0x00007ffda63a9000)
        libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f2134fa3000)
        libtinfo.so.5 => /usr/lib/libtinfo.so.5 (0x00007f2134f3f000)
        libz.so.1 => /usr/lib/libz.so.1 (0x00007f2134d28000)
        libm.so.6 => /usr/lib/libm.so.6 (0x00007f2134ba3000)
        libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f2134b82000)
        libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f21349f3000)
        libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f21349d7000)
        libc.so.6 => /usr/lib/libc.so.6 (0x00007f2134813000)
        /usr/lib64/ld-linux-x86-64.so.2 (0x00007f213706b000)

Too bad, it would have been so nice to have the two work peacefully together. :(

Anyway, I think that the only feature of faustgen~ which we don't have in faust~ right now is the auto-compile facility. That could be added, but in fact recompiling and reloading dsps is already pretty convenient in pd-faust if you're using Emacs. Other than that, faust~ should provide a proper superset of what faustgen~ currently does.

It's really nice, though, that we now have faustgen~ as a light-weight, no-frills alternative which is much easier to install than faust~. I'll be recommending it to my students this semester, although we'll still be using faust~ in the courses as we'll need its additional features.

BTW, thanks @pierreguillot for the heads-up about the redrawing of the xlets. :) It turned out to be a lot more complicated to do this in pd-pure than in faustgen~, but I have it working now.