Failed running application on X86.

[Beth]

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

[Colin Burgess]

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

[Beth]

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

[David Rempel]

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

[Beth]

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:

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

[Colin Burgess]

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

[Beth]

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

[Beth]

I took out the usefile, it didn't help. Failed on the same instruction. dlopen().

-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

[Colin Burgess]

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

[Beth]

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

[Colin Burgess]

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

[Allan]

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

[Allan]

"Allan" <apkleywegt@qnx.com> wrote in message
news:ac0j02$moi$2@nntp.qnx.com...

What file system is the shared library being loaded from? Local? Remote?

Can other shared objects be loaded from the same location?

[Beth]

I totally agree. That's why I don't want to give up.
-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

[Beth]

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:

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