libtool
[Top][All Lists]
Advanced

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

RE: Shared library with U suffix not installed


From: Lawrence, David (STEI)
Subject: RE: Shared library with U suffix not installed
Date: Sun, 27 May 2001 21:27:52 -0700

Alexandre,

I will try to clarify, but please understand that I am new to developing in
Linux and am porting a fairly large project that was built using perl
scripts to the Autotools environemnt.  I apologize if I have misunderstood
your request.  I appreciate your patience.

I have already created a series of make files that build the project.  Now I
am trying to use the Autotool environment to do the same thing.

The -shared argument was part of the command line options to cc in the
original build environemnt.  I preserved that when I created a build
environment using make files.  When I went to using Autotools, I missed
adding the -shared flag to the list of arguments to gcc.  When I noticed
that -static wasn't being passed to gcc when building the various output
files, I added it to each of the Makefile.am files in LDFLAGS.  This fixed
the unresolved external that was preventing the building of an executable,
but apparently was not enough for two of the shared libraries.

Using make from the root of a build tree that was different than the source
tree, I was able to sucessfully compile and link everything.  However, when
I attempted to install the software to a "staging" area using:

        make DESTDIR=/tmp install

two of the four shared libraries were not copied to the staging area.
Instead, the shared file names for the two libraries were changed by adding
a U suffix to the library name (libdmi2api.so.0.0.0 became
libdmi2api.so.0.0.0U).

The output to stderr from the above make install request follows by
signature.  It would appear that libtool is not able to locate one of the
dependent directories.  Is there something I can do to assist?

One additional note about my environment.  It already has the shared
libraries installed.  Previously they were built without versioning.  Only
libname.so is in the lib install directory.  Libtool believes this is a
first time install ... at least that is my assumption because the libname.la
file in the build tree src directory (not the .libs directory) states the
library is not installed.  I am using a temporary staging area for testing
the install to avoid updating the previously installed libraries.

David Lawrence
address@hidden

libtool: install: warning: remember to run `libtool --finish
/usr/local/lib/dmi'
libtool: install: warning: remember to run `libtool --finish
/usr/local/lib/dmi'
libtool: install: warning: relinking `libdmi2api.la'
/usr/bin/ld: cannot find -ldmiutil
collect2: ld returned 1 exit status
libtool: install: error: relink `libdmi2api.la' with the above command
before installing it
libtool: install: warning: remember to run `libtool --finish
/usr/local/lib/dmi'
libtool: install: warning: `../wrap2/libdmi2api.la' has not been installed
in `/usr/local/lib/dmi'
libtool: install: warning:
`/home/davel/dev/EmergingProducts/LinuxDMISP_base/build/src/dmiutil/libdmiut
il.la' has not been installed in `/usr/local/lib/dmi'
libtool: install: warning:
`/home/davel/dev/EmergingProducts/LinuxDMISP_base/build/src/dmiapi/libdmiapi
.la' has not been installed in `/usr/local/lib/dmi'
libtool: install: warning: `../dmiapi/libdmiapi.la' has not been installed
in `/usr/local/lib/dmi'
libtool: install: warning: `../dmiutil/libdmiutil.la' has not been installed
in `/usr/local/lib/dmi'
libtool: install: warning: relinking `libdmionc.la'
/usr/bin/ld: cannot find -ldmiutil
collect2: ld returned 1 exit status
libtool: install: error: relink `libdmionc.la' with the above command before
installing it
libtool: install: warning: remember to run `libtool --finish
/usr/local/lib/dmi'





-----Original Message-----
From: Alexandre Oliva [mailto:address@hidden
Sent: Sunday, May 27, 2001 3:08 PM
To: Lawrence, David (STEI)
Cc: 'Robert Boehne'; 'address@hidden'
Subject: Re: Shared library with U suffix not installed


On May 27, 2001, "Lawrence, David (STEI)" <address@hidden> wrote:

> The only thing I could see that was different was that the -shared
> option was being passed on my non Gnu Autotools version.

Can you please clarify the actual situation in which -shared was being
used?  -shared is used to create a shared libraries, and, in general,
shared libraries may have unresolved symbols, that will be expected to
be supplied by whatever program is linked with them.


> Two of the four shared libraries are not moved during the make
> install step.  Instead, the library is renamed with a U suffix.  I
> am assuming that this means these libraries have unresolved
> references and libtool and the install process are trying to
> highlight the problem.

libtool doesn't do anything like that.  I have no idea of where the U
is coming from.  Can you please post the exact install command and the
symptom?

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  address@hidden, redhat.com}
CS PhD student at IC-Unicamp        address@hidden, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me



reply via email to

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