Project

General

Profile

Bug #2533

Automake on Solaris

Added by kukackajiri over 6 years ago. Updated over 6 years ago.

Status:
Fixed
Priority:
Low
Category:
-
Target version:
ASK QUESTIONS IN Forums:

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

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

Updated by stbuehler over 6 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.

#2

Updated by kukackajiri over 6 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.

#3

Updated by stbuehler over 6 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).

#4

Updated by stbuehler over 6 years ago

  • Target version set to 1.4.34
#5

Updated by stbuehler over 6 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 :)

#6

Updated by kukackajiri over 6 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.

#7

Updated by stbuehler over 6 years ago

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

Applied in changeset r2928.

Also available in: Atom