Re: creating shared libraries

[Brendan J Simon <brendan.simon@bigpond.com>]

More info.
It turns out that fopen() works perfectly from a user app that is 
compiled directly.  ie. the fopen() call is made from the app source 
code.  If the fopen() is called from within a library, the app just 
hangs.  It can be killed with ctrl-c.  It is not device driver specific 
either.  The same thing happens if I try to fopen a text file.

Development host is a PowerMac running a combination of stable and 
testing.  I'm using the compiler that comes with debian (2.95.4) but the 
C libraries are 2.2.5 which have been compiled and placed under 
configuration management.  ie. not linking with the active C library on 
the host.

The funny thing is that shared C libraries work fine so I assume it's a 
problem with the way I'm generating my custom library.  I've read the 
docs and am using -fPIC and -shared flags.  I noticed on another mailing 
list that ppd is also compiled with the -DPIC flag.  Is this necessary???

Thanks for any help,
Brendan Simon.


Brendan J Simon wrote:

> I have some programs running on an embedded powerpc board 
> (linuxppc-2.4.18).  The program is statically linked to my own library 
> and works really well, _BUT_ I'm running out of room on my filesystem 
> so I want to create shared libraries and link all my apps to the 
> shared libraries.
>
> I seem to be able to link OK and the apps run up until a point and 
> then just hangs.  It seems that when the library tries to open a 
> device driver using fopen() it just hangs.  A printk in the device 
> driver open routine never gets called.  It seems something is blocking 
> and the process is sleeping.  The kernel doesn't die and the app can 
> be killed.  Further investigation shows that this only happens with 
> fopen() but not with open().
>
> Has ayone seen anything like this?  I assume it's something wrong with 
> the way the shared library is being created and/or compiled.  Maybe 
> it's the device driver but I really don't know.
>
> Any help, pointers or suggestions will be greatly appreciated.
> Thanks,
> Brendan Simon.