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.
