Re: Building Secondary Modules

[Jerome Vuarand <jerome.vuarand@...>]

2010/6/23 Antonio Scuri <scuri@tecgraf.puc-rio.br>:
>> 2010/6/23 Antonio Scuri <scuri@tecgraf.puc-rio.br>:
>> >  I have two modules. One is straight forward to build. But the second
>> one
>> > depends on C functions that were implemented in the first module.
>> >
>> >  So when linking the second module in Linux I have to add the first
>> module
>> > using "-lmodule1". But it fails, because the first module is called
>> > "module1.so" and not "libmodule1.so".
>> >
>> >  I know there are "alternative" solutions, like creating a symbolic
>> link
>> > (but do I have to distribute the link? I check using ldd that it
>> depends on
>> > the link, not to the actual file. Ugly...), or use standard names and
>> change
>> > the LUA_CPATH (like I do in IUP). Or even build a base library to
>> store
>> > those functions and link both libraries to that library, but that's
>> nonsense
>> > just to store a couple of functions.
>> >
>> >  So I would like to know if there are other solutions. I searched the
>> Wiki
>> > with no success.
>>
>> You can use -l: (notice the colon) instead of -l to specify an exact
>> filename to ld.
>
>  Hi Jerome,
>
>  Thanks for the quick answer.
>
>  Yes, doing "-l:module1.so" works. It has the same effect of adding the "module1.so" file to the command line. It links. But since "module1.so" is not built in the current directory, running ldd "module2.so" shows that the path "-L../lib" is added to the dependencies:
>
> ldd module2.so
>        ../lib/module1.so => not found

That's because the path ("../lib/module1.so") is written as text in
module2.so. The problem is that you want to use the file
../lib/module1.so at link time, but you want the linker to write
"module1.so" instead of the full path in the import table of
module2.so. There may be a ld option to do that. You should also be
able to patch the so file yourself. You can also try to have a look at
libtool, it might be able to do the job.

Totally unrelated, but when building Lua on one of my Linux boxes,
with the -lreadline link option, the resulting binary ("lua", the
interpreter) run through ldd shows the dependency is only
"libreadline.so", not the fully qualified path. So there must be a way
to tell ld to store only the unqualified dll filename. You can try to
use an absolute path in your -L command rather than a relative one.
Otherwise dig into ld documentation (though I've been unsuccessful on
that path).