Bug #2533
closed
Added by kukackajiri over 11 years ago.
Updated over 11 years ago.
Description
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.
Files
- 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.
man libtool:
-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.
- 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
buffer_copy_string_buffer .libs/mod_flv_streaming.o
http_chunk_append_file .libs/mod_flv_streaming.o
data_string_init .libs/mod_flv_streaming.o
buffer_init_string .libs/mod_flv_streaming.o
array_get_element .libs/mod_flv_streaming.o
buffer_copy_string_len .libs/mod_flv_streaming.o
buffer_is_empty .libs/mod_flv_streaming.o
response_header_overwrite .libs/mod_flv_streaming.o
config_check_cond .libs/mod_flv_streaming.o
array_free .libs/mod_flv_streaming.o
array_init .libs/mod_flv_streaming.o
config_insert_values_global .libs/mod_flv_streaming.o
stat_cache_get_entry .libs/mod_flv_streaming.o
buffer_init .libs/mod_flv_streaming.o
buffer_free .libs/mod_flv_streaming.o
chunkqueue_get_append_buffer .libs/mod_flv_streaming.o
array_insert_unique .libs/mod_flv_streaming.o
array_get_unused_element .libs/mod_flv_streaming.o
array_reset .libs/mod_flv_streaming.o
buffer_is_equal_string .libs/mod_flv_streaming.o
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.
Hm, right. In this case I think we should remove it completely. I'll try to find out if there was a reason for it, but I doubt it (we could enable it in the "NO_RDYNAMIC" case).
- Target version set to 1.4.34
Did you actually check the binaries (modules) are working without -no-undefined? It wouldn't help fixing the build if the result is broken :)
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.
- Status changed from Reopened to Fixed
- % Done changed from 0 to 100
Applied in changeset r2928.
Also available in: Atom
[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
error.
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 <stbuehler@web.de>
git-svn-id: svn://svn.lighttpd.net/lighttpd/branches/lighttpd-1.4.x@2928 152afb58-edef-0310-8abb-c4023f1b3aa9