Created attachment 279729 [details] Build log I'm reporting this bug because the package in summary fails to build when forcing --as-needed on through spec files (check out http://blog.flameeyes.eu/2008/11/14/problems-and-mitigation-strategies-for-as-needed for details). Please note that this bug _might_ apply to -Wl,--as-needed in LDFLAGS as well; in both cases it should be fixed. Also, if this is due to the package in question not respecting user-defined LDFLAGS, you should get to fix that too. Check the attached build log. Thanks, Diego
Hello! Before digging into this, I looked at HEAD from github. It now incorporates a static jemalloc and won't be fun to work with :( Anyway. Onwards to action. (In reply to comment #0) > Created attachment 279729 [details] > Build log > > I'm reporting this bug because the package in summary fails to build when > forcing --as-needed on through spec files (check out > http://blog.flameeyes.eu/2008/11/14/problems-and-mitigation-strategies-for-as-needed > for details). I'm unable to reproduce this on my x86_64 (gcc-4.5.2) through specfiles. Linking works as intended: make[2]: Leaving directory `/var/tmp/portage/dev-db/redis-2.2.11/work/redis-2.2.11/deps/hiredis' x86_64-pc-linux-gnu-gcc -o redis-benchmark -std=c99 -pedantic -Wall -W -D__EXTENSIONS__ -D_XPG6 -O2 -pipe -lm -pthread -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu ae.o anet.o redis-benchmark.o sds.o adlist.o zmalloc.o ../deps/hiredis/libhiredis.a x86_64-pc-linux-gnu-gcc -o redis-cli -std=c99 -pedantic -Wall -W -D__EXTENSIONS__ -D_XPG6 -O2 -pipe -lm -pthread -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu anet.o sds.o adlist.o redis-cli.o zmalloc.o release.o ../deps/hiredis/libhiredis.a ../deps/linenoise/linenoise.o x86_64-pc-linux-gnu-gcc -o redis-check-dump -std=c99 -pedantic -Wall -W -D__EXTENSIONS__ -D_XPG6 -O2 -pipe -lm -pthread -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu redis-check-dump.o lzf_c.o lzf_d.o x86_64-pc-linux-gnu-gcc -o redis-check-aof -std=c99 -pedantic -Wall -W -D__EXTENSIONS__ -D_XPG6 -O2 -pipe -lm -pthread -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu redis-check-aof.o x86_64-pc-linux-gnu-gcc -o redis-server -std=c99 -pedantic -Wall -W -D__EXTENSIONS__ -D_XPG6 -O2 -pipe -lm -pthread -Wl,-O1 -Wl,--as-needed -Wl,--hash-style=gnu adlist.o ae.o anet.o dict.o redis.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 vm.o pubsub.o multi.o debug.o sort.o intset.o syncio.o > > Please note that this bug _might_ apply to -Wl,--as-needed in LDFLAGS as well; > in both cases it should be fixed. Also, if this is due to the package in > question not respecting user-defined LDFLAGS, you should get to fix that too. The ebuild is respecting user-defined LDFLAGS, I confirmed this by changing them in my /etc/make.conf. Linking with --as-needed works from here as well. > > Check the attached build log. > > Thanks, > Diego Thanks for the input. Is this perhaps 32-bit only? I've got a 32bit image tucked away, will give it a try later on.
FYI: This is 32-bit only, and adding -m32 to ARCH (TARCH) doesn't help (this is how upstream wants you to build 32 bit builds). I'll have a closer look at this shortly, but we should file a bug upstream.
This is *not* 32-bit only, it is *forced* --as-needed only. You got -lm passed _before_ the LDFLAGS, so if you simply have -Wl,--as-needed in LDFLAGS, it won't apply to -lm. OTOH with forced --as-needed, -lm is discarded as well.
(In reply to comment #3) > This is *not* 32-bit only, it is *forced* --as-needed only. > > You got -lm passed _before_ the LDFLAGS, so if you simply have -Wl,--as-needed > in LDFLAGS, it won't apply to -lm. OTOH with forced --as-needed, -lm is > discarded as well. What I meant was that I was only able to reproduce with *forced* --as-needed on my 32-bit install, not the 64-bit one.
FYI: Same error on 2.2.12. Diego: Could you perhaps file an upstream bug? I read your comment as me walking in the dark, so I'd appreciate if you could post proper details so upstream tackles the issue correctly. Thanks!
Upstream issue here: http://code.google.com/p/redis/issues/detail?id=615 Please comment if I'm giving misleading information.
Guess I should mention that this was fixed upstream some weeks ago. Commit for 2.2 brand found here: https://github.com/antirez/redis/commit/e1f01c9b28751d71ba0df682fb0f6b62f4db9191
I updated to the .12 and added the patch, thanks for the notice.
