le this would work, it has the (IMHO) nasty side affect that any
libraries previously installed in, say /usr/lib, will take priority (I
think) over the library that was just built in the source code tree.
It also means hacking around with the Makefiles.
--
Brian May <[EMAIL PROTECTED]>
when creating Debian packages).
If an old copy of the library exists in /usr/lib, then that will get
used instead of the library that has just been compiled.
--
Brian May <[EMAIL PROTECTED]>
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
arched /usr/lib first(??), it might link the wrong version of
the library.
My preferred fix would be to replace instances of
.../path/to/lib/liba.la
with something like
.../path/to/lib/.libs/liba.so
which would be guaranteed to get the correct library.
--
Brian May <[EMAIL PROTECTED]>
_
>>>>> "Brian" == Brian May <[EMAIL PROTECTED]> writes:
>>>>> "Alexandre" == Alexandre Oliva <[EMAIL PROTECTED]> writes:
Alexandre> The problem has to do with requiring relinking at
Alexandre> install time. This is ne
>>>>> "Brian" == Brian May <[EMAIL PROTECTED]> writes:
Alexandre> In general, when relinking is necessary, you must not
Alexandre> use a different prefix to install than the one used to
Alexandre> build.
Brian> In which case, you are
o, why did this work with libtool 1.4, but then suddenly stop
working?
--
Brian May <[EMAIL PROTECTED]>
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
#x27;.
make[1]: Leaving directory `/home/bam/tmp/libtool-1.4/mdemo'
[note: this test conducted on a stable Debian system; it also fails on
unstable. It use to work on unstable, the only change I can think of
is Linux 2.4.4 instead of 2.4.3 and glibc 2.2.3 instead of 2.2.2 ]
--
Brian May <[EMAIL PROTECTED]>
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
nk convenience libraries need to compile two sets
of libraries: *.a which contains non-PIC code and *.al which contains
PIC code.
--
Brian May <[EMAIL PROTECTED]>
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
look at this, I will, after I am satisfied the
previous problems have been fixed (with regards to interlibrary
dependencies).
--
Brian May <[EMAIL PROTECTED]>
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
>>>>> "Brian" == Brian May <[EMAIL PROTECTED]> writes:
Brian> /usr/lib/libz.so -> libz.so.1.1.3 /usr/lib/libz.la ->
Brian> libz.la.1.1.3 /usr/lib/libz.so.1 -> libz.so.1.1.3
Brian> /usr/lib/libz.so.1.1.3 /usr/lib/libz.la.1.1.3
Me a
et matters straight (I am still not quite sure of
this). For situation
i) what linking libx.la, the version pointer to by libx.so is used?
ii) when dlopening libx.la, the version pointed to by libx.so is used?
--
Brian May <[EMAIL PROTECTED]>
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
>>>>> "Brian" == Brian May <[EMAIL PROTECTED]> writes:
Alexandre> Presumably, libz.la would be that from the older
Alexandre> version, since libz.la is used for linking. And then,
Alexandre> because libtool sets dlname to the SONAME of the
Alexandre> latest version thereof (as per the lib package). Or
Alexandre> something like that :-)
Agreed.
In the discussion on debian-policy, there was some concern that this
system would break ldconfig, but it appears that these concerns are
not justified. For instance ldc
his is already a potential
problem (programs designed for libz.so.1 could mistakenly use the
libz.la file from libz.so.2 build). So I won't consider these
problems here.
Any comments?
--
Brian May <[EMAIL PROTECTED]>
___
Libtool mailing list
(eg. the
run time search path specifying the installation path - at least this
way it should work, I think?).
No sense in breaking a feature on *all* platforms just because some
can't cope...
--
Brian May <[EMAIL PROTECTED]>
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
that is the programmers fault, and libtool shouldn't go out of its way
to try and resolve/break the issue.
--
Brian May <[EMAIL PROTECTED]>
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
roject. Then it adds the
Wesley> right -L options.
That seems to help the 2nd problem, Thanks.
Any ideas on the first problem?
--
Brian May <[EMAIL PROTECTED]>
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
ared l2.lo -L/usr/lib -ll1 -Wl,-soname -Wl,libl2.so.0 -o
.libs/libl2.so.0.0.0
/usr/bin/ld: cannot find -ll1
collect2: ld returned 1 exit status
libtool: install: error: relink `libl2.la' with the above command before installing it
libtool: install: warning: remember to run `libtool --fini
>>>>> "Kevin" == Kevin Ryde <[EMAIL PROTECTED]> writes:
>> On Tue, Jan 16, 2001 at 01:50:57PM +1100, Brian May wrote: >
>> Oh, another observation: installing the libraries in their
>> non-final > location (as required for Debia
ken from Heimdal).
(oh, before my patch the upstream version also had:
libvers_la_LDFLAGS = -static
which meant non-PIC code was compiled in the shared libraries. I didn't
like this, so removed it).
--
Brian May <[EMAIL PROTECTED]>
___
Li
depdemo.static
/home/bam/source/cvs/libtool/depdemo/a/bin/depdemo.static
/usr/bin/install -c depdemo.static
/home/bam/source/cvs/libtool/depdemo/a/bin/depdemo.static
make[2]: Nothing to be done for `install-data-am'.
make[2]: Leaving directory `/ho
>>>>> "Brian" == Brian May <[EMAIL PROTECTED]> writes:
Brian> Hello, according to the
Brian> http://www.gnu.org/software/libtool/>, the mailing
Brian> list archives for this mailing list are kept at
Brian> http://www.geocrawler.com/l
er.com/archives/3/404/2000/9/0/4316399/>
(although that prediction seems to be overly optimistic now :-(. )
So, is there anything wrong with the mailing list and/or archives, or
is there nothing worth getting discussed?
--
Brian May <[EMAIL PROTECTED]>
23 matches
Mail list logo
