9 Jul
2012
9 Jul
'12
11:47 p.m.
On Mon, Jul 09, 2012 at 09:41:44PM +0200, Robin Gareus wrote:
On 07/09/2012 09:18 PM, John Rigg wrote:
It was the -lm option. With that added to the LD line in the makefile
it could find cos, which was the undefined symbol stopping demolition.
Other undefined symbols like malloc, calloc and free didn't bother it
(these could be defined with the -l:libc.so option but it wasn't
necessary).
Thanks,
John
I'm trying to test my new LADSPA plugin with
demolition but
the latter fails due to undefined symbols. Running objdump -t on
the .so lists several of the standard C functions used in the code
as undefined symbols. I've tried installing libc6-dbg and adding
-g to the CFLAGS in the makefile (which is a modified version of
the one in ladspa_sdk) but it makes no difference.
System is Debian testing amd64 (pre-multi-arch snapshot from
Jan 2012). I thought it might be due to a mismatch in the build
tools, so I tried building the plugin on Debian Lenny (5.0.3).
The same thing happens there.
I've tried running demolition on a couple of the Debian packaged
swh-plugins and it runs without a problem, but any plugin I compile
from source (not just mine) gives the same type of error.
All of the undefined symbols are standard libc functions like malloc,
calloc, free, cos etc. The plugin works perfectly in Ardour2 on both
systems. Anyone have any ideas how to fix this?
since Lenny, Debian switched to multi-arch support. libs will be in
/usr/lib/<triplet>/ instead of /usr/lib/ NTL the linker should find
them -- but check /etc/ld.so.conf.d/* and /etc/ld.so.conf if you've
upgraded from Lenny or use an early testing system.
To get the standard libs, it is necessary to explicitly use
LOADLIBES="-lrt -lm" when linking objects these days.