[Date Prev][Date Next][Thread Prev][Thread Next]
- Subject: Re: Why does the default cpath not have lib?.so in it?
- From: liam mail <liam.list@...>
- Date: Tue, 13 Sep 2011 09:08:09 +0100
On 13 September 2011 06:46, Geoff Leyland <email@example.com> wrote:
> On 13/09/2011, at 5:12 PM, Alex Ames wrote:
>> I feel like I'm probably missing something obvious here, so forgive me
>> if this is a silly question.
> I don't think it's a silly question, but I'm afraid I can't answer most of it, however,
>> I could change the linux .so to not have the lib prefix, but I'm not
>> even sure how to do this with gcc automatically. AFAIK it
>> automatically prepends "lib" and I'd have to go change it manually
>> every time I recompile.
> How are you invoking cc (ld/install...)? For me, "cc -shared test.c" creates a library called a.out and "cc -shared test.c -o test.so" makes a library called test.so, not libtest.so.
> Just in case, "cc main.c -ltest" does expect a libtest.so to be available, but you usually don't link to Lua modules at compile time, and I don't think that's your problem.
Yes Lua loadable shared objects drop the prefix of lib and even
require '.so' on Mac Osx, this is not a great problem as the SO is
really only intended to be used by Lua. If for any reason this would
be problematic you could always introduce a symlink foo.so ->
libfoo.dyld. As Geff points out it is very easy to tell gcc what name
to use rather than the default of libName.so or libName.dyld