ther_flags $i" ;; # add it to output
esac ;;
esac
done
ord_libs=
if $libs_l; then
for i in $rev_libs; do
case " $ord_libs " in
*\ $i\ *) ;;# already there
*) ord_libs="$i $ord_libs" ;; # add it to output in
_la_LIBADD = -L../somedir -L../somedir/.libs -lbar
This has made me a little nervous, so I wanted to check to see if this
is likely to work OK, either under 1.4.2 or prior versions, or if this
could be expected to cause trouble.
Thanks
--
Rob Browning
rlb @defaultvalue.org, @linuxdeve
mean time, anyone care to suggest what the flag
> should be? --preserve-dup-deps ???
As another data point. I we installed your ltmain.sh in gnucash and
link times on a 1Ghz athlon went from two hours to ten minutes, and
everything still seems to work OK.
Thanks.
--
Rob Browning
rlb @defau
tool seems likely to involve
fairly awkward library filesystem placement, and LD_LIBRARY_PATH
tricks.
If people think this is a good idea, I'd be happy to help write the
code.
Thanks
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58
e compile line.
But though I've had some agreement from relevant developers, I
wouldn't expect to see this any time soon.
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5
e the foo 1.1 version in /usr/lib.
Now you can get around this by changing the order above, but that
won't scale, and breaks if the situation wrt foo and gnome were
reversed.
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GP
an package that seems to
fix the problem for some people, but still doesn't work for other
package like guile and heimdal.
Thanks
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C 64AE
libguile_la_LIBADD = @LIBLOBJS@ $(LIBLTDL) $(THREAD_LIBS_LOCAL)
libguile_la_LDFLAGS = -version-info
@LIBGUILE_INTERFACE_CURRENT@:@LIBGUILE_INTERFACE_REVISION@:@LIBGUILE_INTERFACE_AGE@
-export-dynamic -no-undefined
where $(THREAD_LIBS_LOCAL) := ../qt/libqthreads.la
--
Rob Browning
rlb @defau
) so
that we don't regress in the future.
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Rob Browning <[EMAIL PROTECTED]> writes:
> How would people feel about the addition of a new function
>
> lt_dlhandle lt_dlopen_interface(const char *name, int interface_number);
So do the libtool maintainers have any opinion about this one way or
the other? As it stand
s a better
suggestion, I'd be happy to hear it.
Hope this helps.
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD
___
Libtool mailing list
[EMAIL
cking around with the Makefiles.
Agreed, but for me right now, it's better than nothing, and I needed
*some* fix to allow some needed inter-lib dependencies to be included
in the 1.4 packages.
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GP
look at the source and perform some
tests, but this seems like it might solve our problems, and if it does
work, then perhaps some variation on this approach might be acceptable
to the libtool maintainers.
Thoughts?
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously
libfoo) and not worry about the
fact that the library's eventually going to be in /usr/lib...
I'm curious about your suggestion because the hack I'm using right now
is causing problems, and I'm going to have to come up with something
better. I've even thought of
s true with Debian -- minimizing the Debian diff
is a good idea, all other things being equal. In any case, thanks so
much. I'll try this -- it looks like a good solution.
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previou
Rob Browning <[EMAIL PROTECTED]> writes:
> Agreed -- the same is true with Debian -- minimizing the Debian diff
> is a good idea, all other things being equal. In any case, thanks
> so much. I'll try this -- it looks like a good solution.
That appeared to work perfe
e ... install
or similar.
Hope this helps.
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
to /opt/guile-1.5, you will be unable to compile or link a
gtk app against guile 1.5 if any of the gtk config scripts output
-L/usr/lib and those flags appear before -lguile on the link line.
On Linux and similar systems, could libtool, foo-config scripts,
etc. just special case (and omit) -L/usr/
- it was
causing all manner of problems here. Why does ltdl need to implement
its own memory management anyway?
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD
___
op-flags, or perhaps better,
--begin-group --end-group as someone recently mentioned,
but that's not going to help on all architectures...
--
Rob Browning
rlb @defaultvalue.org, @linuxdevel.com, and @debian.org
Previously @cs.utexas.edu
GPG=1C58 8B2C FB5E 3F6
20 matches
Mail list logo
