From: <no...@so...> - 2002-03-28 16:09:05
|
Bugs item #535176, was opened at 2002-03-26 12:53 You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=101627&aid=535176&group_id=1627 Category: Filter network Group: critical Status: Open Resolution: None Priority: 5 Submitted By: Stefan Kost (ensonic) Assigned to: Daniel Kobras (nold) Summary: Failed to create importing network Initial Comment: I am trying glame since 0.6.0 up to 0.6.2 and still get the "failed to create importing network" error when importing a wav (tried various one) - they all very simple. I belive it has something to do how do you handle plugins. Are you using glib::gmodule or own dlopen-stuff? my system : >uname -a SunOS krishna 5.6 Generic_105181-12 sun4u sparc SUNW,Ultra-60 configure options : '--prefix=/opt/BKgnome' '--with-gnu-ld' '--enable-ladspa' '--disable-asm' 'CC=gcc' --enable-ltdl-convenience build and install went through fine. ---------------------------------------------------------------------- >Comment By: Richard Guenther (richi) Date: 2002-03-28 16:09 Message: Logged In: YES user_id=7575 Ok, after crosschecking with other archs I have access to, I'll commit the new check to the stable branch. The gcc version looks ok, so the difference is the DEBUG define - which results in debugging messages to be printed. So the difference will be caused by src/include/util.h - placing an #undef HAVE_GCC at the top of the file may fix this and give some hints... ---------------------------------------------------------------------- Comment By: Stefan Kost (ensonic) Date: 2002-03-28 16:04 Message: Logged In: YES user_id=250654 there is indeed pthread_join in libc nm /usr/lib/libc.a | grep pthread_join 00000940 W _pthread_join 00000940 W pthread_join but they all marked as weak. In contrans in /usr/lib/libpthread.so they are physically there. I noticed that __pthread_init is not in the libc. If you need I could attach the outputs of but nm commands (libc and libpthread). Anyway, I've tested the new acx-pthread.m4 and it works. Thanks a lot. I'll try various opots for --enable-debug soon, my gcc is gcc --version 2.95.2 ---------------------------------------------------------------------- Comment By: Richard Guenther (richi) Date: 2002-03-28 15:39 Message: Logged In: YES user_id=7575 I checked in a new acx-pthreads.m4 file into the unstable branch which should fix the SunOS issues. I also attached it to this bug, just replace your macros/acx-pthread.m4 with the updated version and re-generate the configure files using autogen.sh. ---------------------------------------------------------------------- Comment By: Richard Guenther (richi) Date: 2002-03-28 15:26 Message: Logged In: YES user_id=7575 Ok, it seems the pthread check thinks that not linking with -lpthread is ok (the "checking whether threads work without any explicit flags... yes" line). Can you check, if pthread_join is contained in SunOS libc? Can you check for a symbol contained in libpthread but not in libc, so I can fix the check? If there is no such symbol I'll probably have to add a "if SunOS then do things different". Thanx for tracking this down, Richard. Also the --enable-debug thing _may_ be a compiler problem (we compile with -O0) - can you try adjusting the CFLAGS for the debug case in configure.in to -g -O (you need to regenerate the configure stuff by using the ./autogen.sh script)? Btw. which version of gcc are you using? ---------------------------------------------------------------------- Comment By: Stefan Kost (ensonic) Date: 2002-03-28 15:02 Message: Logged In: YES user_id=250654 After I have taken out --enable-debug, it doesn't crashes anymore and much better with the previous setenv PTHREAD_LIBS -lpthread now running (test-latency 10) gives me 10 - ping time 1009 usec 9 - ping time 828 usec 8 - ping time 885 usec 7 - ping time 807 usec 6 - ping time 800 usec 5 - ping time 801 usec 4 - ping time 796 usec 3 - ping time 817 usec 2 - ping time 796 usec 1 - ping time 796 usec ---------------------------------------------------------------------- Comment By: Stefan Kost (ensonic) Date: 2002-03-28 12:24 Message: Logged In: YES user_id=250654 All I did is to do setenv PTHREAD_LIBS -lpthread so that I now have this line in all Makefiles running it in ddd (frontend for gdb) says : Program received signal SIGSEGV, Segmentation fault. 0xeefa4614 in strlen () ... I'll trace it further ---------------------------------------------------------------------- Comment By: Richard Guenther (richi) Date: 2002-03-27 16:14 Message: Logged In: YES user_id=7575 The segfault looks interesting... can you try to debug that? Can you try to provide extra CFLAGS (-pthread or the like)? Thanx, Richard. ---------------------------------------------------------------------- Comment By: Stefan Kost (ensonic) Date: 2002-03-27 15:20 Message: Logged In: YES user_id=250654 I've recompiled it with --enable-debug then run cglame cglame> (test-latency 10) Segmentation fault (core dumped) btw.: in generated Makefile I have PTHREAD_CC = gcc PTHREAD_CFLAGS = PTHREAD_LIBS = configure said checking pthread.h usability... yes checking pthread.h presence... yes checking for pthread.h... yes checking for pthread_attr_init in -lpthreads... no checking whether threads work without any explicit flags... yes checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE checking if more special flags are required for pthreads... no ---------------------------------------------------------------------- Comment By: Richard Guenther (richi) Date: 2002-03-26 14:33 Message: Logged In: YES user_id=7575 Also you may want to check if with SunOS you need extra CFLAGS like f.i. -pthread to enable pthread support in libc/compiler. I can see our pthread autoconf macro doesnt specifically check things for SunOS/Solaris. ---------------------------------------------------------------------- Comment By: Daniel Kobras (nold) Date: 2002-03-26 14:29 Message: Logged In: YES user_id=7832 Uh-uh, this smells like pthreads suckage. We don't have a Solaris machine to test on, so we'll need your help to track this down. Now the good news is, dlopening seems to work, otherwise test-latency would have failed even earlier. As for the pthreads issue, a test-latency run from a cglame compiled with --enable-debug would be really enlightening. ---------------------------------------------------------------------- Comment By: Stefan Kost (ensonic) Date: 2002-03-26 13:46 Message: Logged In: YES user_id=250654 glame> (test-latency 10) ERROR: In procedure filter-launch in expression (filter-launch net): ERROR: unhandled-exception: glame-error ABORT: (misc-error) ---------------------------------------------------------------------- Comment By: Daniel Kobras (nold) Date: 2002-03-26 13:35 Message: Logged In: YES user_id=7832 Uhmm..., SunOS's not exactly a well-tested platform, so can you check whether filter networks do run at all? Fire up the command line interface 'cglame' and type '(test-latency 1)' to run a really basic filter network. Furthermore, if you configured glame with --enable-debug, the console output might be pretty helpful to find out what's going on. dlopen-screwage seems rather unlikely since importing doesn't rely on external plugins. We're using libtool's ltdl for dynamic loading. ---------------------------------------------------------------------- Comment By: Richard Guenther (richi) Date: 2002-03-26 13:33 Message: Logged In: YES user_id=7575 We are using libltdl for dlopen stuff. Can you try something with the console frontend? Try > cglame cglame> (test-latency 10) and watch, if it correctly counts down from 10 to 1 (ping times on my athlon here are about 180 usecs). This checks if basic networks do work correctly (i.e. indicate pthreads problems). If this works ok, try to access a dynamically loaded plugin like cglame> (plugin-get "null") it should print something like #<pointer 0x80de5a0> on success and throw an exception on error. ---------------------------------------------------------------------- You can respond by visiting: http://sourceforge.net/tracker/?func=detail&atid=101627&aid=535176&group_id=1627 |