automake
[Top][All Lists]
Advanced

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

Re: Library locations


From: Russell Shaw
Subject: Re: Library locations
Date: Mon, 06 Aug 2007 10:53:24 +1000
User-agent: Thunderbird 1.5.0.2 (X11/20060501)

Ralf Wildenhues wrote:
Hello Braden, Russell,

* Braden McDaniel wrote on Sun, Aug 05, 2007 at 08:27:07PM CEST:
On Mon, 2007-08-06 at 03:49 +1000, Russell Shaw wrote:
I want it to be like:

   System_LTLIBRARIES = modules/System/system.la
   modules_System_system_la_SOURCES = modules/System/system.c
   modules_System_system_la_LDFLAGS = -module

That makes "modules/System/system.la" ok, but it still puts
system.o and system.lo in the top level src directory.

The latter feature is governed by the Automake option subdir-objects.
Note that the option has existed for a long time, but its functionality
has been improved lately, e.g., for non-C sources.  See the NEWS file
for details.

Hi,
I forgot about that option.

Look again. That's entirely inconsistent with my experience with
automake's (1.10) behavior. The object file generated from the above
should be "modules/System/modules_System_system_la-system.lo".

Then you have subdir-objects set.

That means the program won't work in the uninstalled state,
because dlopen is looking for system.o as modules/System/system.o.
That seems unlikely. dlopen should be looking for system.so. I don't
imagine it cares about the location of system.o.

I agree with Braden here, dlopen should not care about object positions
and things should work with subdir-objects and without.  If you have a
failure setup, please show us how to reproduce it.

I have:

  AUTOMAKE_OPTIONS = subdir-objects

  System_LTLIBRARIES = modules/System/system.la
  modules_System_system_la_SOURCES = modules/System/system.c
  modules_System_system_la_LDFLAGS = -module
  AM_LDFLAGS = -export-dynamic

and now it works better with:

  modules/System/system.la
  modules/System/system.lo
  modules/System/system.o

generated.


However, the shared object that dlopen requires is in a new .libs directory:

  modules/System/.libs/system.o
  modules/System/.libs/system.so
  modules/System/.libs/system.so.0
  modules/System/.libs/system.so.0.0.0


Dlopen fails because it is looking for modules/System/system.so
When installed, i'll have the install location at:

  /usr/lib/$(pkglibdir)/System/system.so


Should i just have dlopen look for modules/System/.libs/system.so
and modules/System/system.so and use the first one that succeeds, or
is there a cleaner way for avoiding this?

Also, what's the best way to determine from within the program whether
it is currently installed or not?




reply via email to

[Prev in Thread] Current Thread [Next in Thread]