Bug #2533

Automake on Solaris

Added by kukackajiri about 1 year ago. Updated 11 months ago.

Status:FixedStart date:2013-11-25
Priority:LowDue date:
Assignee:-% Done:

100%

Category:-
Target version:1.4.34
Missing in 1.5.x:No

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.

automake-libtool-Solaris.patch Magnifier (10.6 KB) kukackajiri, 2013-11-25 15:19

Associated revisions

Revision 2928
Added by stbuehler 11 months ago

[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 <>

History

#1 Updated by stbuehler about 1 year 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.

#2 Updated by kukackajiri about 1 year 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.

#3 Updated by stbuehler about 1 year 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).

#4 Updated by stbuehler about 1 year ago

  • Target version set to 1.4.34

#5 Updated by stbuehler about 1 year 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 :)

#6 Updated by kukackajiri about 1 year 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.

#7 Updated by stbuehler 11 months ago

  • Status changed from Reopened to Fixed
  • % Done changed from 0 to 100

Applied in changeset r2928.

Also available in: Atom