Seems related to bug 466180?
Created attachment 360054 [details] build log
Created attachment 360056 [details] emerge --info
Created attachment 360058 [details] emerge -pqv output
Created attachment 360060 [details] environment
I see -lwebp but not -lwebpdemux in the command-line. What version of libwebp are you using? When you unpack chromium sources and run 'python tools/compile_test/compile_test.py --code "int main() { return 0; }" --run-linker --on-success "-lwebp -lwebpdemux" --on-failure "-lwebp" -- -lwebpdemux', what does it print? As a more basic test, please try compiling the simple program from above manually and link webp and webpdemux and post what happens.
(In reply to Paweł Hajdan, Jr. from comment #5) > I see -lwebp but not -lwebpdemux in the command-line. > > What version of libwebp are you using? 0.3.1 > > When you unpack chromium sources and run 'python > tools/compile_test/compile_test.py --code "int main() { return 0; }" > --run-linker --on-success "-lwebp -lwebpdemux" --on-failure "-lwebp" -- > -lwebpdemux', what does it print? -lwebp > > As a more basic test, please try compiling the simple program from above > manually and link webp and webpdemux and post what happens. cat > test.c int main() { return 0; } gcc -lwebp -lwebpdemux -o test test.c /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../lib64/libwebp.so: undefined reference to `pthread_join' /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../lib64/libwebp.so: undefined reference to `pthread_create' collect2: error: ld returned 1 exit status
(In reply to Richard Freeman from comment #6) > gcc -lwebp -lwebpdemux -o test test.c > /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../lib64/libwebp.so: > undefined reference to `pthread_join' > /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../lib64/libwebp.so: > undefined reference to `pthread_create' > collect2: error: ld returned 1 exit status Does revdep-rebuild rebuild anything? What if you just re-emerge libwebp?
It seems like your libwebpdemux might be missing a NEEDED entry for libpthread.
(In reply to Paweł Hajdan, Jr. from comment #7) > (In reply to Richard Freeman from comment #6) > > gcc -lwebp -lwebpdemux -o test test.c > > /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../lib64/libwebp.so: > > undefined reference to `pthread_join' > > /usr/lib/gcc/x86_64-pc-linux-gnu/4.7.3/../../../../lib64/libwebp.so: > > undefined reference to `pthread_create' > > collect2: error: ld returned 1 exit status > > Does revdep-rebuild rebuild anything? What if you just re-emerge libwebp? No, and no difference, at least not to the output of the command above (I didn't try rebuilding all of chromium yet, but I will kick that off now before I head out for the evening).
Could you attach a libwebp build log?
Created attachment 360092 [details] libwebp build log
Created attachment 360094 [details] floppym's libwebp build log Interesting, configure seems to be misdetecting the -pthread switch. From your log: configure: checking for threading support... checking for the pthreads library -lpthreads... no checking whether pthreads work without any flags... yes checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE checking if more special flags are required for pthreads... no checking for PTHREAD_PRIO_INHERIT... no configure: checking if threading is enabled... yes From my log: configure: checking for threading support... checking for the pthreads library -lpthreads... no checking whether pthreads work without any flags... no checking whether pthreads work with -Kthread... no checking whether pthreads work with -kthread... no checking for the pthreads library -llthread... no checking whether pthreads work with -pthread... yes checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE checking if more special flags are required for pthreads... no checking for PTHREAD_PRIO_INHERIT... no configure: checking if threading is enabled... yes
Maybe check config.log to see exactly how configure is compiling the test program for that.
Created attachment 360102 [details] config log From my config.log: checking whether pthreads work without any flags x86_64-pc-linux-gnu-gcc -o conftest -march=amdfam10 -Os -pipe -frename-registers -fweb -freorder-blocks -freor der-blocks-and-partition -flto=5 -funit-at-a-time -ftree-pre -fgcse-sm -fgcse-las -fgcse-after-reload -fmerge-all-constants -ftree-vectorize -ftree-parallelize-loops=4 -mabm -msse4a -fstack-protector -Wl,-O1 -Wl,--as-needed -Wl,--as-needed -Wl,--sort-common -march=amdfam10 -Os -pipe -frename-registers -fweb -freorder-blocks -freorder-blocks-and-partition -flto=5 -funit-at-a-time -ftree-pre -fgcse-sm -fgcse-las -fgcse-after-reload -fmerge-all-constants -ftree-vectorize -ftree-parallelize-loops=4 -mabm -msse4a -fstack-protector conftest.c $? = 0
I did some testing and dropping -ftree-parallelize-loops=4 results in: /tmp/ccMFkAMY.ltrans0.ltrans.o: In function `main': ccMFkAMY.ltrans0.o:(.text.startup+0x14): undefined reference to `pthread_create' ccMFkAMY.ltrans0.o:(.text.startup+0x1f): undefined reference to `pthread_join' ccMFkAMY.ltrans0.o:(.text.startup+0x48): undefined reference to `__pthread_register_cancel' ccMFkAMY.ltrans0.o:(.text.startup+0x52): undefined reference to `__pthread_unregister_cancel' collect2: error: ld returned 1 exit status Including that parameter results in a successful compilation of conftest.c. So, it seems that this option is what is causing issues.
Something else which is odd - my CFLAGS are being added to the command line twice. If I try to override them using /etc/portage/env then I get both my default CFLAGs and my override CFLAGs in the command line. Something is appending default flags to the command line, alongside whatever logic is taking into account /etc/portage/env. As a result I couldn't test different CFLAGS by just overriding the environment variable - I had to create my own conftest.c and manually run the command lines outside of portage.
(In reply to Richard Freeman from comment #16) > Something else which is odd - my CFLAGS are being added to the command line > twice. > > If I try to override them using /etc/portage/env then I get both my default > CFLAGs and my override CFLAGs in the command line. > > Something is appending default flags to the command line, alongside whatever > logic is taking into account /etc/portage/env. As a result I couldn't test > different CFLAGS by just overriding the environment variable - I had to > create my own conftest.c and manually run the command lines outside of > portage. Disregard just this post - I figured out the cause of that and it is unrelated. So, libwebp is definitely fixable by using more tame CFLAGS. Even so, that issue might still be useful to somebody.
Looking through the gcc manual: -ftree-parallelize-loops=n Parallelize loops, i.e., split their iteration space to run in n threads. This is only possible for loops whose iterations are independent and can be arbitrarily reordered. The optimization is only profitable on multiprocessor machines, for loops that are CPU- intensive, rather than constrained e.g. by memory bandwidth. This option implies -pthread, and thus is only supported on targets that have support for -pthread. So, -ftree-parallelize-loops implies -pthread, which causes the configure behavior we see. This is the libtool command that is run to link libwebpdemux: /bin/sh ../../libtool --tag=CC --mode=link x86_64-pc-linux-gnu-gcc -Wall -Wdeclaration-after-statement -Wextra -Wmissing-declarations -Wmissing-prototypes -Wold-style-definition -Wshadow -Wunused-but-set-variable -Wunused -Wvla -march=amdfam10 -Os -pipe -frename-registers -fweb -freorder-blocks -freorder-blocks-and-partition -flto=5 -funit-at-a-time -ftree-pre -fgcse-sm -fgcse-las -fgcse-after-reload -fmerge-all-constants -ftree-vectorize -ftree-parallelize-loops=4 -mabm -msse4a -fstack-protector -no-undefined -version-info 0:1:0 -Wl,-O1 -Wl,--as-needed -Wl,--as-needed -Wl,--sort-common -march=amdfam10 -Os -pipe -frename-registers -fweb -freorder-blocks -freorder-blocks-and-partition -flto=5 -funit-at-a-time -ftree-pre -fgcse-sm -fgcse-las -fgcse-after-reload -fmerge-all-constants -ftree-vectorize -ftree-parallelize-loops=4 -mabm -msse4a -fstack-protector -o libwebpdemux.la -rpath /usr/lib64 demux.lo ../libwebp.la libtool: link: x86_64-pc-linux-gnu-gcc -shared -fPIC -DPIC .libs/demux.o -Wl,-rpath -Wl,/var/tmp/portage/media-libs/libwebp-0.3.1/work/libwebp-0.3.1-amd64/src/.libs ../.libs/libwebp.so -march=amdfam10 -Os -flto=5 -mabm -msse4a -Wl,-O1 -Wl,--as-needed -Wl,--as-needed -Wl,--sort-common -march=amdfam10 -Os -flto=5 -mabm -msse4a -Wl,-soname -Wl,libwebpdemux.so.0 -o .libs/libwebpdemux.so.0.0.1 I wonder if libtool is stripping the -ftree-parallelize-loops=4 option from the linker command?
(In reply to Mike Gilbert from comment #18) > I wonder if libtool is stripping the -ftree-parallelize-loops=4 option from > the linker command? First we are pretty aggressively stripping CFLAGS in chromium. Then actually the compile_test.py above doesn't respect CFLAGS. I think that would address the problem here. Let's keep this bug open while I figure out the fix - thank you very much for identifying which CFLAG is causing the problem. I might also end up stripping flags in libwebp.
(In reply to Paweł Hajdan, Jr. from comment #19) > (In reply to Mike Gilbert from comment #18) > > I wonder if libtool is stripping the -ftree-parallelize-loops=4 option from > > the linker command? > > First we are pretty aggressively stripping CFLAGS in chromium. > > Then actually the compile_test.py above doesn't respect CFLAGS. I think that > would address the problem here. > I am fairly sure that the problem should be resolved in the libwebp package. It should be adding a DT_NEEDED libpthread.so.1 entry to libwebpdemux.so, but something is preventing that. I think the CFLAGS used to compile chromium are irrelevant.
Created attachment 360534 [details] phajdanjr-libwebp-build-log.gz
I can't repro here. I've tried adding "-ftree-parallelize-loops=4 -fopenmp" to CFLAGS, rebuilding libwebp and rebuilding chromium. It works. My libwebpdemux.so and libwebp.so have libpthread.so in DT_NEEDED.
