On 19.12.18 13:07, Chris Lamb wrote:
> tags 916831 - moreinfo
> thanks
> 
> Hi Matthias,
> 
>> export DEB_LDFLAGS_MAINT_APPEND =  -Wl,--as-needed -ldl -latomic 
>> $(LUA_LDFLAGS)
>>
>> probably should do the trick.
> 
> Bingo:
> 
>   cc -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -ldl -latomic -llua5.1-cjson 
> -llua5.1-bitop ../deps/lua/src/lua_struct.o ../deps/lua/src/lua_cmsgpack.o  
> -g -ggdb -rdynamic -o redis-server adlist.o quicklist.o ae.o anet.o dict.o 
> server.o sds.o zmalloc.o lzf_c.o lzf_d.o pqsort.o zipmap.o sha1.o ziplist.o 
> release.o networking.o util.o object.o db.o replication.o rdb.o t_string.o 
> t_list.o t_set.o t_zset.o t_hash.o config.o aof.o pubsub.o multi.o debug.o 
> sort.o intset.o syncio.o cluster.o crc16.o endianconv.o slowlog.o scripting.o 
> bio.o rio.o rand.o memtest.o crc64.o bitops.o sentinel.o notify.o 
> setproctitle.o blocked.o hyperloglog.o latency.o sparkline.o 
> redis-check-rdb.o redis-check-aof.o geo.o lazyfree.o module.o evict.o 
> expire.o geohash.o geohash_helper.o childinfo.o defrag.o siphash.o rax.o 
> t_stream.o listpack.o localtime.o lolwut.o lolwut5.o -llua5.1 -ljemalloc -lm 
> -ldl -pthread -lrt -lhiredis
>   /usr/bin/ld: scripting.o: in function `luaLoadLibraries':
>   ./src/scripting.c:844: undefined reference to `luaopen_cjson'
>   /usr/bin/ld: ./src/scripting.c:847: undefined reference to `luaopen_bit'
>   collect2: error: ld returned 1 exit status
>   make[3]: *** [Makefile:242: redis-server] Error 1
>   make[3]: *** Waiting for unfinished jobs....
>   make[3]: Leaving directory '/tmp/buildd/redis-5.0.3/src'
>   make[2]: *** [Makefile:6: all] Error 2
>   make[2]: Leaving directory '/tmp/buildd/redis-5.0.3'
>   dh_auto_build: make -j9 "INSTALL=install --strip-program=true" V=1 
> USE_SYSTEM_JEMALLOC=yes USE_SYSTEM_LUA=yes USE_SYSTEM_HIREDIS=yes returned 
> exit code 2
> 
>> But generally it's wrong to pass libs in any LDFLAGS.
> 
> They are optional libraries loaded at runtime. Is this an exception?
> (Am I doing this wrong?)

If they are loaded at runtime, they probably shouldn't be referenced in the
binary by linking. But then you have to manage the dependency yourself, by
either hard-coding the shared library names in the dependencies, or by deducing
these names by the dependencies of the -dev packages.  E.g. openjdk is
hard-coding the library packages for a number of libraries which are dl-opened.

But are the really loaded at runtime? scripting.o seems to have a hard-coded
reference, which is needed for linking?

Matthias

Reply via email to