On Tue, 11 Mar 2008 13:43:35 -0700 "Pharaoh ." <pharaoh137@xxxxxxxxx> wrote: > On Tue, Mar 11, 2008 at 10:32 AM, John Utz <john.utz@xxxxxxx> wrote: > > > On Mon, 10 Mar 2008 16:41:03 -0700 > > "Pharaoh ." <pharaoh137@xxxxxxxxx> wrote: > > > > > On Mon, Mar 10, 2008 at 3:03 PM, Pharaoh . <pharaoh137@xxxxxxxxx> > > > wrote: > > > > > > > > On Mon, Mar 10, 2008 at 1:58 PM, John Utz <john.utz@xxxxxxx> > > > > 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@xxxxxxxxx> 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@xxxxxxxxxxxxxxxx > > > > > > 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 write hmm, 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! _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
