RE: Shared library with U suffix not installed

[Lawrence, David (STEI)]

Alexandre,

Thank you for your suggestion.  Unfortunately rearranging the libraries did
not correct the problem.  I did have another version of the project that was
not using the Gnu Autotools that compiled and linked successfully, so I
reviewed the output of both build processes.  The only thing I could see
that was different was that the -shared option was being passed on my non
Gnu Autotools version.  When I added -shared to LDFLAGS for the build that
was failing, the error disappeared and the executable linked successfully.

Any ideas why this might be the case?  As another possible clue, I cannot
find the unresolved reference as being defined anywhere in the source tree.
(The reference was in the static library).  Is it possible that when you
link with -shared that unused functions are dropped from the library (or at
least not placed in the shared library of executable), potentially removing
the unresolved reference from the output file because the function that
contained it was never called by any of the code in the executable?  I am
forcing the statis library with -static.  Is it possible that this is a
contributing factor?

I'm not quite successful yet.  The problem that I originally was having
during make install has resurfaced.  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.  I just don't know how to correct the problem.
Rebuilding the libraries with the -shared option did not clear this problem.

David Lawrence
address@hidden


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


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

> Sorry, I meant to mention that RmiInvoke is defined in the static library
> comutil (../comutil/libcomutil.la).  The library is linked with both the
> shared library libdmiapi.so and the daemon oncsp.

In the case of static libraries, the order matters.  ld will only
search a static library once.  Since the need for RmiInvoke is only
introduced afterwards, the linker doesn't bring in the definition from
the dependence library that appeared before.  Reorder the dependences
such that dependent libraries appear before dependencies and all
should be fine.

-- 
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