Is the libtool-commit ML supposed to work anymore? I've not seen a message
there for sometime now.
Thanks,
Nick
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
When is a 1.5 or 1.5.1 tarball going to be made available?
Thanks,
Nick
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
On Tuesday 22 July 2003 2:32 pm, [EMAIL PROTECTED] wrote:
> [EMAIL PROTECTED] wrote:
> > On Tuesday 22 July 2003 2:02 pm, Peter O'Gorman wrote:
> > > Firstly, in case you were wondering why libtool builds static libraries
> > > even for loadable modules, libtool via. ltdl supports loading modules
On Tuesday 22 July 2003 2:02 pm, Peter O'Gorman wrote:
>
> On Tuesday, July 22, 2003, at 09:37 PM, Sander Niemeijer wrote:
> >
> >
> > In our situation it is not possible to just disable building of static
> > libraries on a global level for our package, since our package
> > provides multiple
Subject says it all.
Thanks,
Nick
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
psym_cmds, $1)='$CC -shared $libobjs $deplibs $compiler_flags ${wl}-soname $wl$soname ${wl}-retain-symbols-file $wl$export_symbols -o $lib'
fi
;;
2003-01-31 Nick Hudson <[EMAIL PROTECTED]>
* libtool.m4: don't use -nodefaultlibs in archive{,_expsym}_commands
On Monday 25 November 2002 2:43 pm, Max Horn wrote:
> An alternate solution might be to change the kbackgammon exectuable
> to load the kbackgammon.so, too, instead of linking against it. Or is
> there anything else that needs to link against these loadable modules?
Why? What benefit is there in
On Monday 25 November 2002 10:47 am, David wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: RIPEMD160
>
>
> > Feel free to take the patches from NetBSD pkgsrc and makes noises with
> > the KDE people. http://www.netbsd.org/Documentation/software/packages.html
> >
> No need to make noise with
On Monday 25 November 2002 10:04 am, Guido Draheim wrote:
> It's the correct solution AFAICS - from the same sources two
> libtool libraries are built - one is a system library that
> gets linked to the system binary. And the module libtool
> archive is separate from that. Both .la will be able to
On Sunday 24 November 2002 6:23 pm, Benjamin Reed wrote:
> One of the problems we're running into getting KDE working on Darwin is
> libtool's concept of a "module", and how it's mapped onto Darwin's
> linker behavior.
This was talked about some time ago by Michael Matz and myself.
> To get aro
artly because they mix several issues. They are from NetBSD's
> Nick Hudson and for KDE 2.2. I also laid out the general solution, which
> doesn't involve any libtool hacking. Patches implementing that solution
> for KDE 3 are welcome if you don't want to wait for me doi
On Friday 26 October 2001 2:28 pm, scott hutinger wrote:
> This type of thing has caused, and still causes problems on the PPC
> platform (and ARM). Any mixing (which H.J. Lu fully understands) doesn't
> work. The problem is that many platforms (x86) do not see any problems
> with the mixture.
On Thursday 13 September 2001 21:30, Gary V. Vaughan wrote:
> On Wed, Sep 12, 2001 at 07:31:41PM +0100, Nick Hudson wrote:
> > On Tuesday 11 September 2001 19:34, Gary V. Vaughan wrote:
[...]
> > > * ltdl.m4 [AC_LTDL_SYS_DLOPEN_DEPLIBS]: Teach ltdl about the
> > > b
On Tuesday 11 September 2001 19:34, Gary V. Vaughan wrote:
> On Mon, Sep 10, 2001 at 08:29:17PM +0100, Nick Hudson wrote:
> > On Monday 10 September 2001 18:59, Patrick Welche wrote:
> > > I mumbled about mdemo-exec and friends failing a while back, but
> > > hopefully
On Monday 10 September 2001 18:59, Patrick Welche wrote:
> I mumbled about mdemo-exec and friends failing a while back, but hopefully
> this will make the problem a bit clearer:
I already stated that the problem lies in the fact that the configuration
goop expects dlopen to be in a library other
On Tue, 17 Jul 2001 11:22:40 +0100, Patrick Welche wrote:
> On Mon, Jul 16, 2001 at 09:05:40PM +0100, Gary V. Vaughan wrote:
> >
> > I am using automake from the stable branch, and autoconf-2.50, so I
can't
> > vouch for how well things work with development versions... you might
try
> >
Thomas Tanner wrote:
>
> On 26-Apr-2001 Nick Hudson wrote:
> > Is there any reason why I shouldn't be able to install a convience
> > library. For example
>
> > What I'd like is a archive of -fPIC compiled code.
>
> build it as static library an
Is there any reason why I shouldn't be able to install a convience
library. For example
$ libtool --mode=compile cc -c dummy.c -o dummy.o
cc -c dummy.c -fPIC -DPIC -o .libs/dummy.o
cc -c dummy.c -o dummy.o >/dev/null 2>&1
$
$ libtool --mode=link cc -o libconv.la dummy.lo
ar cru .libs/libconv.a .
"Edouard G. Parmelan" wrote:
>
>
> Configuring libtool 1.3e (1.913 2001/04/23 21:59:34)
>
> checking host system type... i386-unknown-netbsd1.4.1
> checking build system type... i386-unknown
Alexandre Oliva wrote:
>
> On Apr 25, 2001, Nick Hudson <[EMAIL PROTECTED]> wrote:
>
> > These fails due to a problem in ld.aout_so (see lib/10940) that has
> > recently been fixed and is available in the netbsd-1-4 tagged sources.
>
> Nick, would you mind s
"Gary V. Vaughan" wrote:
>
> Hi everyone,
> $ ./configure
> ...
>
> Configuring libtool 1.3e (1.900 2001/04/20 20:55:18)
>
> ...
> checking host system type... i686-pc-linux-gnu
This is an
"Gary V. Vaughan" wrote:
>
> Hi everyone,
>
> Failing major disasters, or the discovery of a showstopper, there are less
> than 18 hours to go before the release of libtool-1.4 from CVS HEAD.
>
> I would be grateful for any host triplets (as reported by
> the libtool configure s
Alexandre Oliva wrote:
>
> On Apr 6, 2001, Nick Hudson <[EMAIL PROTECTED]> wrote:
>
> > Michael Matz wrote:
>
> >> 2001-04-05 Michael Matz <[EMAIL PROTECTED]>
> >>
> >> * ltmain.in: recognize "C" as default --tag argument to
Michael Matz wrote:
>
> Hi,
> 2001-04-05 Michael Matz <[EMAIL PROTECTED]>
>
> * ltmain.in: recognize "C" as default --tag argument to resolve
> also ambiguities with that language.
FWIW I've done something similar in NetBSD pkgsrc libtool - I've done it
a different way and c
Michael Matz wrote:
>
> Hi,
>
> On Sun, 1 Apr 2001, Gary V. Vaughan wrote:
> > > >
> > > > I have applied the following to HEAD (and similar to MLB).
> > >
> > > Why also MLB? Was it really broken there too? I ask, because I
> > > _definitely_ got multiple libraries in link commands.
> >
> > T
Michael Matz wrote:
>
> Hi,
>
> On Thu, 29 Mar 2001, Nick Hudson wrote:
> > > > My main problem with changing need_lib_prefix is that its counter
> > > > intuitive to the user and actually breaks some pkgs in NetBSD pkgsrc
> > > > that have mad
Alexandre Oliva wrote:
>
> On Mar 28, 2001, Nick Hudson <[EMAIL PROTECTED]> wrote:
>
> > My main problem with changing need_lib_prefix is that its counter
> > intuitive to the user and actually breaks some pkgs in NetBSD pkgsrc
> > that have made the assumptio
Michael Matz wrote:
>
> Hi,
>
> On Fri, 23 Mar 2001, Nick Hudson wrote:
> > > If you want something that can be both dlopened and linked with, use
> > > -export-dynamic, not -module. The downside is that you won't be able
>
> This might be an option
Alexandre Oliva wrote:
>
> On Mar 19, 2001, Michael Matz <[EMAIL PROTECTED]> wrote:
>
> > Bad. A real cool way around that would be, if libtool itself built (when
> > -module is given) both, the library and the module (which should be
> > possible, as the -module command line should include all
Here in NetBSD land we aren't that happy using file(1) for
deplibs_check_method...
The reason that pass_all can't be used is that on some platforms linking
in a library of the form libfoo.a can cause problems. So Todd suggested
we use echo with file_magic and patterns that ld(1) uses to match sha
On Mon, 19 Mar 2001 12:49:34 +0100 (MET), Michael Matz wrote:
> Hi,
>
> On Thu, 15 Mar 2001, Nick Hudson wrote:
> > KDE2 has a habit of creating modules and then linking them into
> > programs. Now this isn't a problem if the modules are named libNAME.la,
KDE2 has a habit of creating modules and then linking them into
programs. Now this isn't a problem if the modules are named libNAME.la,
but if they are named NAME.la then I see build errors on NetBSD/a.out.
I've attached a simplified exmaple from each of NetBSD/ELF and
NetBSD/a.out.
My main quest
Robert Boehne wrote:
>
> Nick Hudson wrote:
> > Acutally there is a bigger problem here. If archive_cmds uses LD then
> > there is no correct setting of wl. That is when hardcoding library paths
> > and linking a library with archive_cmds wl should be blank and when
Alexandre Oliva wrote:
>
> On Mar 6, 2001, Bryce McKinlay <[EMAIL PROTECTED]> wrote:
>
> > Perhaps it would suffice to simply clear "wl" when entering the
> > incremental mode, assuming we know the linker will always be called
> > directly when doing incremental.
>
> Yep. Please try this patc
For some reason libtool doesn't add in the right goop so that --tag=CC
can be specified and the "default" configuration used. It does work,
however, as a warning is issued and the fallback is the default
configuration. If no tag is specified with an unknown C compiler then
libtool will exit with a
Hello,
Since the cvs server has move I no longer seem to get commit messages.
Has something gone wrong or am I supposed to do something different.
Nick
--
aka [EMAIL PROTECTED], [EMAIL PROTECTED]
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail
Michael Matz wrote:
>
> Hi,
>
> I currently don't have time to really look into it, so the description of
> the current behaviour of libtool might seem a little wishy-washy, but I
> mention it anyway, in case anybody knows right away what caused this:
>
> Basically libtool is relinking when ins
On 26 Oct 2000 06:52:56 -0200, Alexandre Oliva wrote:
> On Oct 26, 2000, Nick Hudson <[EMAIL PROTECTED]> wrote:
>
> > The build system of a package I was trying to build. This build system
would
> > use /usr/bin/cc and libtool would use cc as determined by confi
> On Oct 25, 2000, Nick Hudson <[EMAIL PROTECTED]> wrote:
>
> > the build system would use /usr/bin/cc as the C compiler whereas libtool
> > would pick up cc as the C compiler
>
> What ``build system''? libtool just uses CC and CXX as determined by
>
Robert Boehne wrote:
> Nick:
>
> Could you post a description of the problem this is causing,
> the only problem I could infer is that "libtool" gets re-generated,
> so your compiles take longer. Is there another problem?
The problem I am seeing is that builds would fail because, for example,
t
Robert Boehne wrote:
>
> Nick Hudson wrote:
> >
> > I've been playing more with the MLB in NetBSD pkgsrc and I'm seeing a
> > few problems with tag inferrences. The problem as I see it boils down to
> > the fact that
> >
> > cc = gcc = /usr/bi
I've been playing more with the MLB in NetBSD pkgsrc and I'm seeing a
few problems with tag inferrences. The problem as I see it boils down to
the fact that
cc = gcc = /usr/bin/cc = /usr/bin/gcc = ...
c++ = g++ = /usr/bin/c++ = /usr/bin/g++ = ...
What is the easiest way of getting libtool to inf
The daily snapshot of the head cvs branch isn't available from
ftp.ffii.org at the moment. It seems to have fallen over when Gary move
ltconfig into libtool.m4 and not recovered. Can someone please fix this.
Thanks,
Nick
"Gary V. Vaughan" wrote:
>
> On Thu, Sep 07, 2000 at 12:39:30PM +0100, Nick Hudson wrote:
> > [I hope this is the right place for the page problem...]
> >
> > I've noticed that the
> >
> > http://www.gnu.org/software/libtool/future.html
>
[I hope this is the right place for the page problem...]
I've noticed that the
http://www.gnu.org/software/libtool/future.html
page seems to have a cvs conflict in it. Take a look a the left hand bar
around the "Future Directions" heading
Is there a release schedule for 1.4 or MLB(1.5?). Just
Nick Hudson wrote:
>
> Alexandre Oliva wrote:
> >
> > On Jul 23, 2000, Nick Hudson <[EMAIL PROTECTED]> wrote:
> >
> > > The ML branch doesn't seem to bootstrap with autoconf 2.13 and automake
> > > 1.4.
> [snip]
>
> > Here'
Alexandre Oliva wrote:
>
> On Jul 23, 2000, Nick Hudson <[EMAIL PROTECTED]> wrote:
>
> > The ML branch doesn't seem to bootstrap with autoconf 2.13 and automake
> > 1.4.
[snip]
> Here's a patch that fixes this problem:
Thanks I'll give it a go right now...
Nick
The ML branch doesn't seem to bootstrap with autoconf 2.13 and automake
1.4.
>From sources cvs'd 5 minutes ago.
aclocal: configure.in: 72: macro `AM_PROG_GCJ' not found in library
automake: configure.in: installing `./install-sh'
automake: configure.in: installing `./mkinstalldirs'
automake: con
Patrick Welche wrote:
>
> ltmain.sh generates wrapper scripts with a relink_command defined. In my
> case, said command correctly has -L/usr/local/lib -L/usr/X11R6/lib, but only
> has -Wl,--rpath -Wl,/usr/local/lib, no X11R6. I was hoping that both the -L
> part and the --rpath part would grab $d
Patrick Welche wrote:
>
> As some of the depdemo tests are failing for me under NetBSD-1.5B/i386, I
> just tried running
>
> depdemo-shared.test
> depdemo-make.test
> depdemo-exec.test
>
> I don't understand the last part of the output from depdemo-make.test:
>
> /bin/sh ./libtool --mode=link
50 matches
Mail list logo
