On Tue, Mar 11, 2008 at 3:37 PM, Pharaoh . pharaoh137@gmail.com wrote:
On Tue, Mar 11, 2008 at 2:36 PM, Pharaoh . pharaoh137@gmail.com wrote:
On Tue, Mar 11, 2008 at 2:31 PM, John Utz john.utz@dmx.com wrote:
On Tue, 11 Mar 2008 13:43:35 -0700 "Pharaoh ." pharaoh137@gmail.com wrote:
On Tue, Mar 11, 2008 at 10:32 AM, John Utz john.utz@dmx.com wrote:
On Mon, 10 Mar 2008 16:41:03 -0700 "Pharaoh ." pharaoh137@gmail.com wrote:
On Mon, Mar 10, 2008 at 3:03 PM, Pharaoh . <pharaoh137@gmail.com
wrote: > > On Mon, Mar 10, 2008 at 1:58 PM, John Utz john.utz@dmx.com > wrote: > > here's some places to start: > > > > did you compile the lib as static but the app as shared or > > vice versa? > > > > also, do an ldd on our libasound.so and see if it wants > > libdl: > > > > utz-gnto64 NewProD # ldd /usr/lib/libasound.so > > libm.so.6 => /lib/libm.so.6 (0x00002acc4444d000) > > libdl.so.2 => /lib/libdl.so.2 (0x00002acc446ce000) > > libpthread.so.0 => /lib/libpthread.so.0 > > (0x00002acc448d2000) libc.so.6 => /lib/libc.so.6 > > (0x00002acc44aee000) /lib64/ld-linux-x86-64.so.2 > > (0x0000555555554000) jutz-gnto64 NewProD # > > > > > > > > > > On Mon, 10 Mar 2008 13:41:10 -0700 > > "Pharaoh ." pharaoh137@gmail.com wrote: > > > > > Hi, > > > > > > I have written an user space plugin and the plugin
shared
> > > library is copied on board > > > appropriately, libasound.so is also copied. > > > > > > > > > When I try: > > > > > > #aplay -D omx test.wav //omx is my plugin > > > > > > I get following error: > > > > > > aplay: can't resolve symbol 'snd_dlsym_start > > > > > > > > > Any idea what is the problem? > > > > > > -pharaoh > > > _______________________________________________ > > > Alsa-devel mailing list > > > Alsa-devel@alsa-project.org > > >
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
> > > > > > > > > I have compiled both alsa-lib and alsa-utils as shared > libraries. After doing ldd, I can see that it needs libdl.so > and it is present on the board. Let me try with a clean build > again. >
Still no luck, I get the same error. Is there any way by which I can find out list of unresolved sumbols in a shared library?
nm -D /usr/lib/libasound.so | grep U
I get this, when I run nm on my alsa-lib which is used on board. U __addsf3 U __assert U __ctype_b U __ctype_tolower U __eqsf2 U __errno_location U __fgetc_unlocked U __fixdfsi U __fixsfsi U __floatsisf U __fputc_unlocked U __gesf2 U __gtsf2 U __lesf2 U __ltsf2 U __nesf2 U _exit U accept U access U atof U atoi U atol U bind U bsearch U calloc U ceil U chmod U chown U close U closedir U connect U dladdr U dlclose U dlopen U dlsym U exit U exp U fclose U fcntl U fflush U ffs U fgetc U fgets U floor U fmod U fopen U fork U fprintf U fputc U fputs U free U fwrite U getenv U getgrnam U gethostbyname U getpid U gettimeofday U getuid U ioctl U listen U localeconv U log U log10 U lseek U malloc U memcmp U memcpy U memmove U memset U mlock U mmap U munmap U nanosleep U open U opendir U pipe U poll U pow U pthread_cond_destroy U pthread_cond_init U pthread_cond_signal U pthread_cond_wait U pthread_create U pthread_join U pthread_mutex_destroy U pthread_mutex_init U pthread_mutex_lock U pthread_mutex_trylock U pthread_mutex_unlock U qsort U raise U read U readdir U realloc U recvmsg U rintf U sched_yield U semctl U semget U semop U sendmsg U setlocale U setsid U setsockopt U shmat U shmctl U shmdt U shmget U sigaction U sigemptyset U signal U snprintf U socket U socketpair U sprintf U sqrt U sqrtf U sscanf U stat U stderr U stdout U strcasecmp U strcat U strchr U strcmp U strcpy U strcspn U strdup U strerror U strlen U strncmp U strncpy U strpbrk U strrchr U strtod U strtol U sysconf U ungetc U unlink U usleep U vfprintf U vfscanf U vsnprintf U vsscanf U waitpid U wordexp U wordfree U write
But, I get almost same thing when I do nm on my laptop's alsa-lib, this alsa-lib works.
U _IO_getc U _IO_putc U __assert_fail U __ctype_b_loc U __ctype_tolower_loc U __errno_location U __stack_chk_fail U __strdup U __strtod_internal U __strtol_internal U __xstat U _exit U accept U access U bind U bsearch U calloc U chmod U chown U close U closedir U connect U dladdr U dlclose U dlopen U dlsym U exit U exp U fclose U fcntl U feof U fflush U fgets U floor U fmod U fopen U fork U fprintf U fputs U free U fwrite U getenv U getgrnam U gethostbyname U getpid U gettimeofday U getuid U ioctl U listen U localeconv U log U log10 U lseek U malloc U memcpy U memmove U memset U mlock U mmap U munmap U nanosleep U open U opendir U pipe U poll U pow U pthread_cond_destroy U pthread_cond_init U pthread_cond_signal U pthread_cond_wait U pthread_create U pthread_join U pthread_mutex_destroy U pthread_mutex_init U pthread_mutex_lock U pthread_mutex_trylock U pthread_mutex_unlock U qsort U read U readdir U realloc U recvmsg U rintf U sched_yield U semctl U semget U semop U sendmsg U setlocale U setsid U setsockopt U shmat U shmctl U shmdt U shmget U sigaction U sigemptyset U signal U snprintf U socket U socketpair U sprintf U sqrtf U sscanf U stderr U stdout U strcasecmp U strcat U strchr U strcmp U strcpy U strcspn U strerror U strlen U strncmp U strncpy U strpbrk U strrchr U strstr U sysconf U ungetc U unlink U usleep U vfprintf U vfscanf U vsnprintf U waitpid U wordexp U wordfree U writehmm, i am out of ideas then. other than one more, are you compiling on one platform and then running on another platform that isnt quite the same, ie compiling on x86_64 then running on i586?
these things can cause strange non-obvious errors.
other than that, i am out of ideas. sorry!
I am compiling on my x86 machine for an arm based board, using appropriate toolchain. Thanks John.
I dont have ld-linux.so in my /lib on board, I think that is the reason the symbols are not getting resolved. Let me check.
No no, that is not the reason. I have ld-mclibc.so elf loader.