[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: creating shared libraries

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.
Brendan Simon.

Reply to: