Bug #2533
closedAutomake on Solaris
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
Updated by stbuehler about 11 years ago
- 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.
Updated by kukackajiri about 11 years 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
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.
Updated by stbuehler about 11 years ago
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).
Updated by stbuehler about 11 years ago
Did you actually check the binaries (modules) are working without -no-undefined? It wouldn't help fixing the build if the result is broken :)
Updated by kukackajiri about 11 years 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.
Updated by stbuehler almost 11 years ago
- Status changed from Reopened to Fixed
- % Done changed from 0 to 100
Applied in changeset r2928.
Also available in: Atom