|
Armin Steinhoff
|
Re: dlopen fails and dlerr returns "No dynamic section ..."
|
|
Armin Steinhoff
08/03/2011 6:31 AM
post87782
|
Re: dlopen fails and dlerr returns "No dynamic section ..."
Aleksandar Ristovski wrote:
> I had no doubt that you do make a call to dlopen from your dV but the
> question is what is it linked against? I still think you somehow managed
> to link libc statically (at least dlopen definition).
Yes, that's the point! The dlxxx calls are part of a static library.
But what the linker does seems a little bit unpedictable.
Using the -Bdynamic option shows that "dlopen" and "dlsym" are listed
as undefined in the output of "objdump".
"dlopen" and "dlsym" are working now but the execution of the code of
"dll.so" is crashing ...
However .... I will place the code for the dynamic linking stuff into a
separate shared library and do linking
against libc.so.3 using the -Bdynamic option. Hope this helps ...
Many thanks for your help
--Armin
>
> Please do a 'nm' on your dV and see if dlopen is listed as an undefined
> symbol. I would expect that it is either not listed (since it's
> statically linked) or present and defined (which is not what you'd want
> in an executable).
>
>
>
>
> On 08/02/2011 11:29 AM, Armin Steinhoff wrote:
>> Aleksandar,
>>
>> there are no debug outputs related to dlopen with the dV application
>> ("dyn_debug.txt") ... but dlopen has been called ("dV-dlopen-call.c")
>>
>> The trace file "working_libdll_test.txt" shows a working small test
>> program (same shared object, "libdll_test.c")
>>
>>
>> --Armin
>>
>>
>>
>> Aleksandar Ristovski wrote:
>>> Could you run your executable on 6.5.0:
>>>
>>> # LD_DEBUG=1 ./dV
>>>
>>> and see where is dlopen resolving from?
>>>
>>> (Look for:
>>> debug: Symbol dlopen bound to definition in ...)
>>>
>>>
>>>
>>>
>>> On 08/02/2011 09:04 AM, Armin Steinhoff wrote:
>>>> Aleksandar Ristovski wrote:
>>>> > You are linking libc statically, and in that case dynamic linking won't
>>>> > work.
>>>>
>>>> Not the case ... I'm linking against libs.so.3 ... dV is the
>>>> application:
>>>>
>>>> # objdump -x dV | grep NEEDED
>>>> NEEDED libm.so.2
>>>> NEEDED libsocket.so.2
>>>> NEEDED libcpp.so.4
>>>> NEEDED libph.so.3
>>>> NEEDED libasound.so.2
>>>> NEEDED libSDL-1.2.so.0
>>>> NEEDED libc.so.3
>>>> #
>>>>
>>>> --Armin
>>>>
>>>> >
>>>> >
>>>> >
>>>> > On 08/01/2011 08:29 AM, Armin Steinhoff wrote:
>>>> >> same result with version 6.5 !
>>>> >>
>>>> >>
>>>> >>
>>>> >> _______________________________________________
>>>> >>
>>>> >> OSTech
>>>> >> http://community.qnx.com/sf/go/post87732
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> >
>>>> > OSTech
>>>> > http://community.qnx.com/sf/go/post87756
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> OSTech
>>>> http://community.qnx.com/sf/go/post87758
>>>>
>>>
>>>
>>>...
|
|
|
|
|
|
Armin Steinhoff
|
Re: dlopen fails and dlerr returns "No dynamic section ..."
|
|
Armin Steinhoff
08/03/2011 8:30 AM
post87788
|
Re: dlopen fails and dlerr returns "No dynamic section ..."
Hi Aleksandar,
it's working now also for 6.4.1!!
The special -Bdynamic section must be closed with -lc ....
Thanks
--Armin
Aleksandar Ristovski wrote:
> I had no doubt that you do make a call to dlopen from your dV but the
> question is what is it linked against? I still think you somehow managed
> to link libc statically (at least dlopen definition).
Yes, that's the point! The dlxxx calls are part of a static library.
But what the linker does seems a little bit unpedictable.
Using the -Bdynamic option shows that "dlopen" and "dlsym" are listed
as undefined in the output of "objdump".
"dlopen" and "dlsym" are working now but the execution of the code of
"dll.so" is crashing ...
However .... I will place the code for the dynamic linking stuff into a
separate shared library and do linking
against libc.so.3 using the -Bdynamic option. Hope this helps ...
Many thanks for your help
--Armin
>
> Please do a 'nm' on your dV and see if dlopen is listed as an undefined
> symbol. I would expect that it is either not listed (since it's
> statically linked) or present and defined (which is not what you'd want
> in an executable).
>
>
>
>
> On 08/02/2011 11:29 AM, Armin Steinhoff wrote:
>> Aleksandar,
>>
>> there are no debug outputs related to dlopen with the dV application
>> ("dyn_debug.txt") ... but dlopen has been called ("dV-dlopen-call.c")
>>
>> The trace file "working_libdll_test.txt" shows a working small test
>> program (same shared object, "libdll_test.c")
>>
>>
>> --Armin
>>
>>
>>
>> Aleksandar Ristovski wrote:
>>> Could you run your executable on 6.5.0:
>>>
>>> # LD_DEBUG=1 ./dV
>>>
>>> and see where is dlopen resolving from?
>>>
>>> (Look for:
>>> debug: Symbol dlopen bound to definition in ...)
>>>
>>>
>>>
>>>
>>> On 08/02/2011 09:04 AM, Armin Steinhoff wrote:
>>>> Aleksandar Ristovski wrote:
>>>> > You are linking libc statically, and in that case dynamic linking won't
>>>> > work.
>>>>
>>>> Not the case ... I'm linking against libs.so.3 ... dV is the
>>>> application:
>>>>
>>>> # objdump -x dV | grep NEEDED
>>>> NEEDED libm.so.2
>>>> NEEDED libsocket.so.2
>>>> NEEDED libcpp.so.4
>>>> NEEDED libph.so.3
>>>> NEEDED libasound.so.2
>>>> NEEDED libSDL-1.2.so.0
>>>> NEEDED libc.so.3
>>>> #
>>>>
>>>> --Armin
>>>>
>>>> >
>>>> >
>>>> >
>>>> > On 08/01/2011 08:29 AM, Armin Steinhoff wrote:
>>>> >> same result with version 6.5 !
>>>> >>
>>>> >>
>>>> >>
>>>> >> _______________________________________________
>>>> >>
>>>> >> OSTech
>>>> >> http://community.qnx.com/sf/go/post87732
>>>> >>
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> >
>>>> > OSTech
>>>> > http://community.qnx.com/sf/go/post87756
>>>> >
>>>> >
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> OSTech
>>>>...
|
|
|
|
|
