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

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

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

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

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

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

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

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

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

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

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

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” <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?

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

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

Yes, other shared libraries can be loaded from the same directory.

-Beth

Allan wrote:

“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 <id@address.com> wrote:

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?

Are you closing stderr?

You should see some info when calling dlopen()

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


cburgess@qnx.com

Beth <id@address.com> wrote:

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.

Alright, so the dll itself appears to be ok. What’s different in your
program from the the test case?


cburgess@qnx.com

A lot difference between these two programs. My test program only does dlopen() and
nothing else. The real application has other more than ten objects. But the dlopen()
instruction is the same.

That still didn’t explain why the application worked on ppc and arm but not x86.
BTW, I used the same common.mk file from the application for building the little test
program.

I am trying everything I could think of. Any other suggestions?

-Beth

Colin Burgess wrote:

Beth <> id@address.com> > wrote:
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.

Alright, so the dll itself appears to be ok. What’s different in your
program from the the test case?


cburgess@qnx.com

Can you try to get the DL_DEBUG output? This prints to stderr, so make sure
you don’t close it.

Cheers,

Colin

Beth <id@address.com> wrote:

A lot difference between these two programs. My test program only does dlopen() and
nothing else. The real application has other more than ten objects. But the dlopen()
instruction is the same.

That still didn’t explain why the application worked on ppc and arm but not x86.
BTW, I used the same common.mk file from the application for building the little test
program.

I am trying everything I could think of. Any other suggestions?

-Beth

Colin Burgess wrote:

Beth <> id@address.com> > wrote:
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.

Alright, so the dll itself appears to be ok. What’s different in your
program from the the test case?


cburgess@qnx.com


cburgess@qnx.com