On Fri, Jul 17, 2009 at 10:44 PM, Jon
Peatfield<[log in to unmask]> wrote:
> On Fri, 17 Jul 2009, Nicola Maggi wrote:
>
>> Hello to everyone,
>> maybe this question is a bit off topic but I'm having a lot of trouble
>> with some application using shared libraries.
>
> Probably way off... :-)
;) sorry but I really didn't know where to ask!
>>
>> I have a FPGA .so file which is provided by the FPGA manufacturer.
>> In addition I have .cpp/.h files which defines a class to wrap around
>> some methods to the DLL entry points.
>>
>> If I write a stand-alone application to access this library everything
>> works fine,I can create objects and access .so functions.
>>
>> Anyway I  have to build another object library which uses the FPGA
>> library.
>> the code to load the library seems to work fine:
>> __________________________________________
>> okCUsbFrontPanel *device;
>> if (FALSE == okFrontPanelDLL_LoadLib(NULL)) {
>>                printf("FrontPanel DLL could not be loaded.\n");
>>                DEBUG_TEXT(DFDB_RCDDETECTOR, 15, "raps::constructor:
>> initialized");
>>        // TODO:throw exception
>>        }else{
>>                printf("Frontpanel DLL loaded.\n");
>>                device= new okCUsbFrontPanel();
>>       }
>> __________________________________________
>> When executing device= new okCUsbFrontPanel(); I get a segfault error
>> (exit status 11).
>>
>> I compile my shared library in this way:
>> g++ -shared -ldl -o libReadoutModuleRAPS.so okFrontPanelDLL.o
>> ReadoutModuleRAPS.o
>>
>> where ReadoutModuleRAPS.o is the object of the source in which i used
>> the code above.
>>
>> I really don't understand why does the stand-alone application works
>> and the shared one doesn't.
>> Does anyone have any idea?
>
> About all I can suggest is adding -fPIC to the compilation of the .cc and
> the the link line - you didn't specify how that was being compiled...

If you mean how do I compile my shared library sources here is an
excerpt from Makefile:
______________________________
libReadoutModuleRAPS.so : okFrontPanelDLL.o raps.o DataChannelRAPS.o
ReadoutModuleRAPS.o
	g++ -shared  -fpic -LlibokFrontPanel.so -lROSCore -lers -lDFDebug
${LIBDIR} ${LIBS} -o libReadoutModuleRAPS.so okFrontPanelDLL.o
ReadoutModuleRAPS.o DataChannelRAPS.o raps.o

ReadoutModuleRAPS.o : ReadoutModuleRAPS.cpp
	${CC} ${INCLUDES} -c -DLINUX -DDEBUG_LEVEL=3 $<
DataChannelRAPS.o : DataChannelRAPS.cpp
	${CC} ${INCLUDES} -c -DLINUX -DDEBUG_LEVEL=3 DataChannelRAPS.cpp
raps.o: raps.cpp
	g++ ${INCLUDES} -DDEBUG_LEVEL=3 -DLINUX -c $<
okFrontPanelDLL.o: okFrontPanelDLL.cpp
	g++  -fPIC -DLINUX -c $<
______________________________
Just ignore all the -l switches becouse those are other libraries
which works just fine..
the only important one is -LlibokFrontPanel.so which calls the FPGA
shared library.

As you can see I'm already using -fPIC to compile the cpp library
wrapper but I don't really know if I should use it to compile the
other files too.


> When compiling code to go into shared/dynamic libraries you need to tell the
> compiler that it may be loaded at any memory location.  ie you need
> 'position independent code' which is what -fPIC says to do.  See the gcc
> manpage for more details.
>
> ...
>   -shared
>        Produce a shared object which can then be linked with other
>        objects to form an executable.  Not all systems support this
>        option.  For predictable results, you must also specify the same
>        set of options that were used to generate code (-fpic, -fPIC, or
>        model suboptions) when you specify this option.[1]
> ...
>   -fpic
>       Generate position-independent code (PIC) suitable for use in a
>       shared library, if supported for the target machine.  Such code
>       accesses all constant addresses through a global offset table
>       (GOT).  The dynamic loader resolves the GOT entries when the pro-
>       gram starts (the dynamic loader is not part of GCC; it is part of
>       the operating system). ...
>   -fPIC
>       If supported for the target machine, emit position-independent
>       code, suitable for dynamic linking and avoiding any limit on the
>       size of the global offset table. ...
> ...
>
>> Thank you,
>> Nicola Maggi
>
> I hope it helps.
>
>> ps.I attached the source code of the library- hope I din't break any
>> maling list rule.
>
>  -- Jon
>