Re: dynamic library problem

Re: dynamic library problem

[Alex J Lennon]

[-- Attachment #1: Type: text/plain, Size: 2091 bytes --]


On 12/06/2014 10:07, Ruud den Bekker wrote:
>
> Hi Alex,
>
>  
>
> Recently you posted a fix for a dynamic library loading problem
>
> for the RaspberryPi and a graphic library.
>
>  
>
> I'm now facing a dynamic library not found problem when using
>
> the BeagleBone board RFS in yocto. However, when I use the qemuarm
>
> RFS, everything is running fine.
>
>  
>
> How can I determine the LDFLAGS that are being used for both builds?
>
>  
>
>  
>

Hi Ruud,

(Possibly helpful to others so cc:'d to the list)

If you're referring to the gstreamer1.0-omx work then yes, that was a
little tricky to track down.

It wasn't a "usual" library loading problem though as it was related to
some strange things that the library authors were doing to implement the
equivalent of a static constructor when the library was loaded. There
wasn't an explicit dependency on the library as the raspivid executable
didn't use any exported functions from that library, and bitbake was
passing an option that meant "unneeded" library dependencies were
stripped out. Thus the library wasn't loaded and didn't do the things it
needed to do.

Getting back to the point, it depends on the problem you are seeing, but
assuming that you are getting an error because of a missing library I
guess the first thing to do (which perhaps you already did?) is to look
for the missing library and do,

cd /
find -name libfoo.so

To see if it is actually in the board image.

If it is there then the next step is either to make sure it is being
picked up with something like

export LD_LIBRARY_PATH=/path/to/libfoo
./run_my_exe

It is also useful to install strace for this type of problem and look at
what libraries are being found and loaded

strace run_my_exe

To actually see what bitbake is doing on the server-side I would do
something like

bitbake -f -c devshell my_recipe

cd ../temp
nano log.do_configure

or

cd ../temp
grep LD_FLAGS

I've also found it to be useful to look at the config.log in ${S}

Hope this helps,

Alex
 

[-- Attachment #2: Type: text/html, Size: 5082 bytes --]