Failed running application on X86.
Failed running application on X86.
I have an application that is built for three different processors, x86,
powerpc and strongarm. Same source code, the only difference is the
compile flag -DNTO_X86, -DNTO_PPCBE, -DNTO_ARMLE.
This application ran fine on both powerpc and strongarm. However, it
failed running on X86 at instruction dlopen(). The return code from
dlopen() was "Library can not be found". I had verified that the library
was in the LD_LIBRARY_PATH.
Any suggestion as to how do I debug this problem?
Thanks,
-Beth
powerpc and strongarm. Same source code, the only difference is the
compile flag -DNTO_X86, -DNTO_PPCBE, -DNTO_ARMLE.
This application ran fine on both powerpc and strongarm. However, it
failed running on X86 at instruction dlopen(). The return code from
dlopen() was "Library can not be found". I had verified that the library
was in the LD_LIBRARY_PATH.
Any suggestion as to how do I debug this problem?
Thanks,
-Beth
Re: Failed running application on X86.
Have you made sure that the name of the object on disk is the same
as the SONAME (that you set with -h)?
The only way you can get the not found is if there
Beth <id@address.com> wrote:
--
cburgess@qnx.com
as the SONAME (that you set with -h)?
The only way you can get the not found is if there
Beth <id@address.com> wrote:
I have an application that is built for three different processors, x86,
powerpc and strongarm. Same source code, the only difference is the
compile flag -DNTO_X86, -DNTO_PPCBE, -DNTO_ARMLE.
This application ran fine on both powerpc and strongarm. However, it
failed running on X86 at instruction dlopen(). The return code from
dlopen() was "Library can not be found". I had verified that the library
was in the LD_LIBRARY_PATH.
Any suggestion as to how do I debug this problem?
Thanks,
-Beth
--
cburgess@qnx.com
Re: Failed running application on X86.
Conlin, thanks for your reply.
I don't have -h flag, I used the QNX build process. My common.mk
file looks like the following.
ifndef QCONFIG
QCONFIG=qconfig.mk
endif
include $(QCONFIG)
NAME=swRdnIP
TOPDIR=../../../../../../..
INSTALL_ROOT_nto=$(TOPDIR)/rel
INSTALLDIR=ffs/lib
EXTRA_INCVPATH = $(PROJECT_ROOT)/../include
EXTRA_LIBVPATH = $(TOPDIR)/rel/$(CPUDIR)/$(INSTALLDIR)
include $(MKFILES_ROOT)/qmacros.mk
CCFLAGS += -nostdinc -shared
LDFLAGS = -lm -lsocket
$(PROJECT_ROOT)/../../../../../rel/$(CPUDIR)/$(INSTALLDIR)/swUtil.so
USEFILE=../../swRdnIP.use
include $(MKFILES_ROOT)/qtargets.mk
The fact that the application is running fine on powerpc and strongarm, it is
very puzzling. And also, if
I build the appliation using conventional makefile format, it runs fine on all
three processors.
-Beth
Colin Burgess wrote:
I don't have -h flag, I used the QNX build process. My common.mk
file looks like the following.
ifndef QCONFIG
QCONFIG=qconfig.mk
endif
include $(QCONFIG)
NAME=swRdnIP
TOPDIR=../../../../../../..
INSTALL_ROOT_nto=$(TOPDIR)/rel
INSTALLDIR=ffs/lib
EXTRA_INCVPATH = $(PROJECT_ROOT)/../include
EXTRA_LIBVPATH = $(TOPDIR)/rel/$(CPUDIR)/$(INSTALLDIR)
include $(MKFILES_ROOT)/qmacros.mk
CCFLAGS += -nostdinc -shared
LDFLAGS = -lm -lsocket
$(PROJECT_ROOT)/../../../../../rel/$(CPUDIR)/$(INSTALLDIR)/swUtil.so
USEFILE=../../swRdnIP.use
include $(MKFILES_ROOT)/qtargets.mk
The fact that the application is running fine on powerpc and strongarm, it is
very puzzling. And also, if
I build the appliation using conventional makefile format, it runs fine on all
three processors.
-Beth
Colin Burgess wrote:
Have you made sure that the name of the object on disk is the same
as the SONAME (that you set with -h)?
The only way you can get the not found is if there
Beth <id@address.com> wrote:
I have an application that is built for three different processors, x86,
powerpc and strongarm. Same source code, the only difference is the
compile flag -DNTO_X86, -DNTO_PPCBE, -DNTO_ARMLE.
This application ran fine on both powerpc and strongarm. However, it
failed running on X86 at instruction dlopen(). The return code from
dlopen() was "Library can not be found". I had verified that the library
was in the LD_LIBRARY_PATH.
Any suggestion as to how do I debug this problem?
Thanks,
-Beth
--
cburgess@qnx.com
Re: Failed running application on X86.
You can try using DL_DEBUG to help debug the problem.
eg: DL_DEBUG=1 my_app
This should give you all kinds of information on dynamic loading of libraries.
This might help to shed some light on it.
Beth <id@address.com> wrote:
eg: DL_DEBUG=1 my_app
This should give you all kinds of information on dynamic loading of libraries.
This might help to shed some light on it.
Beth <id@address.com> wrote:
Conlin, thanks for your reply.
I don't have -h flag, I used the QNX build process. My common.mk
file looks like the following.
ifndef QCONFIG
QCONFIG=qconfig.mk
endif
include $(QCONFIG)
NAME=swRdnIP
TOPDIR=../../../../../../..
INSTALL_ROOT_nto=$(TOPDIR)/rel
INSTALLDIR=ffs/lib
EXTRA_INCVPATH = $(PROJECT_ROOT)/../include
EXTRA_LIBVPATH = $(TOPDIR)/rel/$(CPUDIR)/$(INSTALLDIR)
include $(MKFILES_ROOT)/qmacros.mk
CCFLAGS += -nostdinc -shared
LDFLAGS = -lm -lsocket
$(PROJECT_ROOT)/../../../../../rel/$(CPUDIR)/$(INSTALLDIR)/swUtil.so
USEFILE=../../swRdnIP.use
include $(MKFILES_ROOT)/qtargets.mk
The fact that the application is running fine on powerpc and strongarm, it is
very puzzling. And also, if
I build the appliation using conventional makefile format, it runs fine on all
three processors.
-Beth
Colin Burgess wrote:
Have you made sure that the name of the object on disk is the same
as the SONAME (that you set with -h)?
The only way you can get the not found is if there
Beth <id@address.com> wrote:
I have an application that is built for three different processors, x86,
powerpc and strongarm. Same source code, the only difference is the
compile flag -DNTO_X86, -DNTO_PPCBE, -DNTO_ARMLE.
This application ran fine on both powerpc and strongarm. However, it
failed running on X86 at instruction dlopen(). The return code from
dlopen() was "Library can not be found". I had verified that the library
was in the LD_LIBRARY_PATH.
Any suggestion as to how do I debug this problem?
Thanks,
-Beth
--
cburgess@qnx.com
Re: Failed running application on X86.
Setting the DL_DEBUG=1 only gave out the dynamiclibrary loading information when the
program
was starting. It didn't give out any information at the time the program was failing
on instruction
dlopen().
Am I missing something here?
Thanks,
-Beth
David Rempel wrote:
program
was starting. It didn't give out any information at the time the program was failing
on instruction
dlopen().
Am I missing something here?
Thanks,
-Beth
David Rempel wrote:
You can try using DL_DEBUG to help debug the problem.
eg: DL_DEBUG=1 my_app
This should give you all kinds of information on dynamic loading of libraries.
This might help to shed some light on it.
Beth <id@address.com> wrote:
Conlin, thanks for your reply.
I don't have -h flag, I used the QNX build process. My common.mk
file looks like the following.
ifndef QCONFIG
QCONFIG=qconfig.mk
endif
include $(QCONFIG)
NAME=swRdnIP
TOPDIR=../../../../../../..
INSTALL_ROOT_nto=$(TOPDIR)/rel
INSTALLDIR=ffs/lib
EXTRA_INCVPATH = $(PROJECT_ROOT)/../include
EXTRA_LIBVPATH = $(TOPDIR)/rel/$(CPUDIR)/$(INSTALLDIR)
include $(MKFILES_ROOT)/qmacros.mk
CCFLAGS += -nostdinc -shared
LDFLAGS = -lm -lsocket
$(PROJECT_ROOT)/../../../../../rel/$(CPUDIR)/$(INSTALLDIR)/swUtil.so
USEFILE=../../swRdnIP.use
include $(MKFILES_ROOT)/qtargets.mk
The fact that the application is running fine on powerpc and strongarm, it is
very puzzling. And also, if
I build the appliation using conventional makefile format, it runs fine on all
three processors.
-Beth
Colin Burgess wrote:
Have you made sure that the name of the object on disk is the same
as the SONAME (that you set with -h)?
The only way you can get the not found is if there
Beth <id@address.com> wrote:
I have an application that is built for three different processors, x86,
powerpc and strongarm. Same source code, the only difference is the
compile flag -DNTO_X86, -DNTO_PPCBE, -DNTO_ARMLE.
This application ran fine on both powerpc and strongarm. However, it
failed running on X86 at instruction dlopen(). The return code from
dlopen() was "Library can not be found". I had verified that the library
was in the LD_LIBRARY_PATH.
Any suggestion as to how do I debug this problem?
Thanks,
-Beth
--
cburgess@qnx.com
Re: Failed running application on X86.
Does your conventional makefile (that works on x86) add the usemsg?
Colin (starting to grasp at straws)
Beth <id@address.com> wrote:
--
cburgess@qnx.com
Colin (starting to grasp at straws)
Beth <id@address.com> wrote:
Conlin, thanks for your reply.
I don't have -h flag, I used the QNX build process. My common.mk
file looks like the following.
ifndef QCONFIG
QCONFIG=qconfig.mk
endif
include $(QCONFIG)
NAME=swRdnIP
TOPDIR=../../../../../../..
INSTALL_ROOT_nto=$(TOPDIR)/rel
INSTALLDIR=ffs/lib
EXTRA_INCVPATH = $(PROJECT_ROOT)/../include
EXTRA_LIBVPATH = $(TOPDIR)/rel/$(CPUDIR)/$(INSTALLDIR)
include $(MKFILES_ROOT)/qmacros.mk
CCFLAGS += -nostdinc -shared
LDFLAGS = -lm -lsocket
$(PROJECT_ROOT)/../../../../../rel/$(CPUDIR)/$(INSTALLDIR)/swUtil.so
USEFILE=../../swRdnIP.use
include $(MKFILES_ROOT)/qtargets.mk
The fact that the application is running fine on powerpc and strongarm, it is
very puzzling. And also, if
I build the appliation using conventional makefile format, it runs fine on all
three processors.
-Beth
Colin Burgess wrote:
Have you made sure that the name of the object on disk is the same
as the SONAME (that you set with -h)?
The only way you can get the not found is if there
Beth <id@address.com> wrote:
I have an application that is built for three different processors, x86,
powerpc and strongarm. Same source code, the only difference is the
compile flag -DNTO_X86, -DNTO_PPCBE, -DNTO_ARMLE.
This application ran fine on both powerpc and strongarm. However, it
failed running on X86 at instruction dlopen(). The return code from
dlopen() was "Library can not be found". I had verified that the library
was in the LD_LIBRARY_PATH.
Any suggestion as to how do I debug this problem?
Thanks,
-Beth
--
cburgess@qnx.com
--
cburgess@qnx.com
Re: Failed running application on X86.
No, it doesn't. Would the use file cause the problem? I will take it out and try.
Thanks,
-Beth
Colin Burgess wrote:
Thanks,
-Beth
Colin Burgess wrote:
Does your conventional makefile (that works on x86) add the usemsg?
Colin (starting to grasp at straws)
Beth <id@address.com> wrote:
Conlin, thanks for your reply.
I don't have -h flag, I used the QNX build process. My common.mk
file looks like the following.
ifndef QCONFIG
QCONFIG=qconfig.mk
endif
include $(QCONFIG)
NAME=swRdnIP
TOPDIR=../../../../../../..
INSTALL_ROOT_nto=$(TOPDIR)/rel
INSTALLDIR=ffs/lib
EXTRA_INCVPATH = $(PROJECT_ROOT)/../include
EXTRA_LIBVPATH = $(TOPDIR)/rel/$(CPUDIR)/$(INSTALLDIR)
include $(MKFILES_ROOT)/qmacros.mk
CCFLAGS += -nostdinc -shared
LDFLAGS = -lm -lsocket
$(PROJECT_ROOT)/../../../../../rel/$(CPUDIR)/$(INSTALLDIR)/swUtil.so
USEFILE=../../swRdnIP.use
include $(MKFILES_ROOT)/qtargets.mk
The fact that the application is running fine on powerpc and strongarm, it is
very puzzling. And also, if
I build the appliation using conventional makefile format, it runs fine on all
three processors.
-Beth
Colin Burgess wrote:
Have you made sure that the name of the object on disk is the same
as the SONAME (that you set with -h)?
The only way you can get the not found is if there
Beth <id@address.com> wrote:
I have an application that is built for three different processors, x86,
powerpc and strongarm. Same source code, the only difference is the
compile flag -DNTO_X86, -DNTO_PPCBE, -DNTO_ARMLE.
This application ran fine on both powerpc and strongarm. However, it
failed running on X86 at instruction dlopen(). The return code from
dlopen() was "Library can not be found". I had verified that the library
was in the LD_LIBRARY_PATH.
Any suggestion as to how do I debug this problem?
Thanks,
-Beth
--
cburgess@qnx.com
--
cburgess@qnx.com
Re: Failed running application on X86.
I took out the usefile, it didn't help. Failed on the same instruction. dlopen().
-Beth
Beth wrote:
-Beth
Beth wrote:
No, it doesn't. Would the use file cause the problem? I will take it out and try.
Thanks,
-Beth
Colin Burgess wrote:
Does your conventional makefile (that works on x86) add the usemsg?
Colin (starting to grasp at straws)
Beth <id@address.com> wrote:
Conlin, thanks for your reply.
I don't have -h flag, I used the QNX build process. My common.mk
file looks like the following.
ifndef QCONFIG
QCONFIG=qconfig.mk
endif
include $(QCONFIG)
NAME=swRdnIP
TOPDIR=../../../../../../..
INSTALL_ROOT_nto=$(TOPDIR)/rel
INSTALLDIR=ffs/lib
EXTRA_INCVPATH = $(PROJECT_ROOT)/../include
EXTRA_LIBVPATH = $(TOPDIR)/rel/$(CPUDIR)/$(INSTALLDIR)
include $(MKFILES_ROOT)/qmacros.mk
CCFLAGS += -nostdinc -shared
LDFLAGS = -lm -lsocket
$(PROJECT_ROOT)/../../../../../rel/$(CPUDIR)/$(INSTALLDIR)/swUtil.so
USEFILE=../../swRdnIP.use
include $(MKFILES_ROOT)/qtargets.mk
The fact that the application is running fine on powerpc and strongarm, it is
very puzzling. And also, if
I build the appliation using conventional makefile format, it runs fine on all
three processors.
-Beth
Colin Burgess wrote:
Have you made sure that the name of the object on disk is the same
as the SONAME (that you set with -h)?
The only way you can get the not found is if there
Beth <id@address.com> wrote:
I have an application that is built for three different processors, x86,
powerpc and strongarm. Same source code, the only difference is the
compile flag -DNTO_X86, -DNTO_PPCBE, -DNTO_ARMLE.
This application ran fine on both powerpc and strongarm. However, it
failed running on X86 at instruction dlopen(). The return code from
dlopen() was "Library can not be found". I had verified that the library
was in the LD_LIBRARY_PATH.
Any suggestion as to how do I debug this problem?
Thanks,
-Beth
--
cburgess@qnx.com
--
cburgess@qnx.com
Re: Failed running application on X86.
Beth <id@address.com> wrote:
Use objdump -x sharedlib.so | grep NEEDED to check (you might need to check
the dependencies of the dependencies as well)
Maybe this is different between the working and non-working versions?
--
cburgess@qnx.com
Ok, could it be that a shared library that your dll needs is not being found?I took out the usefile, it didn't help. Failed on the same instruction. dlopen().
Use objdump -x sharedlib.so | grep NEEDED to check (you might need to check
the dependencies of the dependencies as well)
Maybe this is different between the working and non-working versions?
--
cburgess@qnx.com
Re: Failed running application on X86.
They all require the same shared library (libsocket.so.2, libm.so.2, libc.so.2). Is
there any difference between x86 and other processors (armle, ppcbe) on loading a
shared library? Since the application is working on those two processors.
Thanks,
-Beth
Colin Burgess wrote:
there any difference between x86 and other processors (armle, ppcbe) on loading a
shared library? Since the application is working on those two processors.
Thanks,
-Beth
Colin Burgess wrote:
Beth <id@address.com> wrote:
I took out the usefile, it didn't help. Failed on the same instruction. dlopen().
Ok, could it be that a shared library that your dll needs is not being found?
Use objdump -x sharedlib.so | grep NEEDED to check (you might need to check
the dependencies of the dependencies as well)
Maybe this is different between the working and non-working versions?
--
cburgess@qnx.com
Re: Failed running application on X86.
You know, this one is going to be one of those times that you slap your head
and say "D'oh!" - WHEN we finally figure it out.
There shouldn't be any difference, especially giving the error that you're
seeing.
Does the dll fail to load if you give a fully qualified path to it?
Beth <id@address.com> wrote:
--
cburgess@qnx.com
and say "D'oh!" - WHEN we finally figure it out.
There shouldn't be any difference, especially giving the error that you're
seeing.
Does the dll fail to load if you give a fully qualified path to it?
Beth <id@address.com> wrote:
They all require the same shared library (libsocket.so.2, libm.so.2, libc.so.2). Is
there any difference between x86 and other processors (armle, ppcbe) on loading a
shared library? Since the application is working on those two processors.
Thanks,
-Beth
Colin Burgess wrote:
Beth <id@address.com> wrote:
I took out the usefile, it didn't help. Failed on the same instruction. dlopen().
Ok, could it be that a shared library that your dll needs is not being found?
Use objdump -x sharedlib.so | grep NEEDED to check (you might need to check
the dependencies of the dependencies as well)
Maybe this is different between the working and non-working versions?
--
cburgess@qnx.com
--
cburgess@qnx.com
Re: Failed running application on X86.
What file system is the shared library being loaded from? Local? Remote?
"Beth" <id@address.com> wrote in message
news:3CE2F26E.BADAD781@address.com...
"Beth" <id@address.com> wrote in message
news:3CE2F26E.BADAD781@address.com...
They all require the same shared library (libsocket.so.2, libm.so.2,
libc.so.2). Is
there any difference between x86 and other processors (armle, ppcbe) on
loading a
shared library? Since the application is working on those two processors.
Thanks,
-Beth
Colin Burgess wrote:
Beth <id@address.com> wrote:
I took out the usefile, it didn't help. Failed on the same
instruction. dlopen().
Ok, could it be that a shared library that your dll needs is not being
found?
Use objdump -x sharedlib.so | grep NEEDED to check (you might need to
check
the dependencies of the dependencies as well)
Maybe this is different between the working and non-working versions?
--
cburgess@qnx.com
Re: Failed running application on X86.
"Allan" <apkleywegt@qnx.com> wrote in message
news:ac0j02$moi$2@nntp.qnx.com...
news:ac0j02$moi$2@nntp.qnx.com...
Can other shared objects be loaded from the same location?What file system is the shared library being loaded from? Local? Remote?
Re: Failed running application on X86.
I totally agree. That's why I don't want to give up. 
-Beth
Colin Burgess wrote:

-Beth
Colin Burgess wrote:
You know, this one is going to be one of those times that you slap your head
and say "D'oh!" - WHEN we finally figure it out.
There shouldn't be any difference, especially giving the error that you're
seeing.
Does the dll fail to load if you give a fully qualified path to it?
Beth <id@address.com> wrote:
They all require the same shared library (libsocket.so.2, libm.so.2, libc.so.2). Is
there any difference between x86 and other processors (armle, ppcbe) on loading a
shared library? Since the application is working on those two processors.
Thanks,
-Beth
Colin Burgess wrote:
Beth <id@address.com> wrote:
I took out the usefile, it didn't help. Failed on the same instruction. dlopen().
Ok, could it be that a shared library that your dll needs is not being found?
Use objdump -x sharedlib.so | grep NEEDED to check (you might need to check
the dependencies of the dependencies as well)
Maybe this is different between the working and non-working versions?
--
cburgess@qnx.com
--
cburgess@qnx.com
Re: Failed running application on X86.
It is loaded from one of the directories on local. I copied the library to /lib,
that didn't help.
I don't think the error message was accurate. I wrote a simple test program to
load this shared library using dlopen(), it worked fine on x86 processor.
-Beth
Allan wrote:
that didn't help.
I don't think the error message was accurate. I wrote a simple test program to
load this shared library using dlopen(), it worked fine on x86 processor.
-Beth
Allan wrote:
What file system is the shared library being loaded from? Local? Remote?
"Beth" <id@address.com> wrote in message
news:3CE2F26E.BADAD781@address.com...
They all require the same shared library (libsocket.so.2, libm.so.2,
libc.so.2). Is
there any difference between x86 and other processors (armle, ppcbe) on
loading a
shared library? Since the application is working on those two processors.
Thanks,
-Beth
Colin Burgess wrote:
Beth <id@address.com> wrote:
I took out the usefile, it didn't help. Failed on the same
instruction. dlopen().
Ok, could it be that a shared library that your dll needs is not being
found?
Use objdump -x sharedlib.so | grep NEEDED to check (you might need to
check
the dependencies of the dependencies as well)
Maybe this is different between the working and non-working versions?
--
cburgess@qnx.com