Automake on Solaris
|Missing in 1.5.x:||No|
Automake on Solaris fails due to libtool. When automake is used, Lighty libraries are linked with -z defs, but that fails on Solaris. There is a patch attached to disable -z defs check on Solaris.
[auto* build] remove -no-undefined from linker flags, as we actually link modules with undefined symbols (fixes #2533)
On platforms that support linking modules with undefined symbols we
actually do it; so most of the time -no-undefined should result in an
On platforms that don't support it, it will result in an error sooner or
later anyway (on those it should build a shared libary with the core
code to link the modules against).
From: Stefan Bühler <email@example.com>
- Status changed from New to Invalid
Looks like a libtool bug on solaris to me. We use libtool because we don't want to deal with the platform.
-no-undefined: declare that a library does not refer to external symbols
I see no reason why we shouldn't be allowed to use this option on all platforms.
#2 Updated by kukackajiri 11 months ago
- Status changed from Invalid to Reopened
When build with -no-undefined on Solaris, you get those undefined symbols at mod_flv_streaming.so (and others as well):
Undefined first referenced
symbol in file
Those symbols are available in lighttpd binary, so modules are working fine, but modules are linked independently on lighttpd binary, so those symbols are really undefined.
It's not a bug of libtool, it's a feature: -no-undefined works differently on each system, on Solaris it uses -z defs which don't allow undefined symbols, on Linux it seems to do nothing.
#6 Updated by kukackajiri 11 months ago
I didn't checked all modules as I don't have test cases for all of them (if you have them, it would be great if you would share), but all modules I checked works greatly, and since this fix is used on Solaris for quite a long time, and I see no issues about that, there is probably nothing broken when -no-undefined is omitted.
Also available in: Atom