Follow-up Comment #1, patch #9996 (group libtool):
It looks like that patch was merged in 2021
(9e8c882517082fe5755f2524d23efb02f1522490) and was included in libtool 2.4.7.
___
Reply to this item at:
mments:
---
Date: Mon 27 Nov 2023 03:53:22 AM UTC By: Olly Betts
Use -Fe with MSVC to specify DLL output filename
This avoids a deprecation warning with current versions of MSVC, and is
documented as supported at least as far back as Visual C 6.0 which was
released i
On 2018-01-24, Josh Soref <jso...@gmail.com> wrote:
> Olly Betts wrote:
> > Using -Fe instead of -o avoids the warning and should be OK with older
> > versions too (the MSVS 2008 docs list -Fe).
>
> That flag is much older than 2008.
>
> https://msdn.microsoft.c
Using -Fe instead of -o avoids the warning and should be OK with older
versions too (the MSVS 2008 docs list -Fe).
Cheers,
Olly
From 0d1a97460cf14d2574db4749f7bf4c2145035c07 Mon Sep 17 00:00:00 2001
From: Olly Betts <o...@survex.com>
Date: Wed, 24 Jan 2018 14:09:23 +1300
Subject: [PATC
On 2010-06-23, Jirka Hladky jhla...@redhat.com wrote:
we have run into a problem where package developed on Debian and packaged for
Fedora had rpath included in binaries. This is bad and forbidden by rpm rules
(rpmlint will mark it as an error).
After long discussion with upstream and
On 2010-06-18, Charles Wilson libt...@cwilson.fastmail.fm wrote:
b3) For these reasons, it's probably best if the package
maintainer also provides rules for embedding the manifest
in binary form into the real exe. How these rules will
deal with the whole lt-*.exe
On 2008-05-25, Charles Wilson [EMAIL PROTECTED] wrote:
+#define LTWRAPPER_OPTION_PREFIX --lt-
+#define LTWRAPPER_OPTION_PREFIX_LENGTH 5
If the idea is that the user can change LTWRAPPER_OPTION_PREFIX, then
hard-coding the length risks a mismatch if they fail to update
On 2008-05-07, Gary V. Vaughan [EMAIL PROTECTED] wrote:
+ - New lt_dloadvise_preload() call to set a hint that only preloadeded
I think lt_dloadvise_preload should be lt_dladvise_preload.
Cheers,
Olly
I noticed that the sed and grep combination in func_lalib_p can be
folded into a single use of sed. I don't think this is likely to
be a hot spot, but it's an easy fix.
I'm not an expert on sed portability but it doesn't seem to fall afoul
of anything in the autoconf manual.
The patch is
On 2008-04-24, Ralf Wildenhues [EMAIL PROTECTED] wrote:
* Olly Betts wrote on Thu, Apr 24, 2008 at 08:04:03AM CEST:
I noticed that the sed and grep combination in func_lalib_p can be
folded into a single use of sed. I don't think this is likely to
be a hot spot, but it's an easy fix.
I'm
On Mon, Jan 14, 2008 at 10:54:41PM +0100, Ralf Wildenhues wrote:
Hello Olly,
* Olly Betts wrote on Thu, Jan 10, 2008 at 07:42:16PM CET:
The output from:
libtool --help --mode=compile
contains:
-prefer-pic try to building PIC objects only
-prefer-non-pic try
The output from:
libtool --help --mode=compile
contains:
-prefer-pic try to building PIC objects only
-prefer-non-pic try to building non-PIC objects only
Firstly, that's poor grammar (try to build would be better).
Secondly, this seems to be the full extent of the documentation
On 2007-12-19, Dustin J. Mitchell [EMAIL PROTECTED] wrote:
I'm trying to build Perl modules, constructed via SWIG, within an
application that is otherwise built with autoconf/automake/libtool.
Has anyone found/created a natural way to do this?
I do it like so (the XS is hand-crafted rather
On 2007-06-23, Peter O'Gorman [EMAIL PROTECTED] wrote:
On Sat, 2007-06-23 at 17:37 +, Olly Betts wrote:
On 2007-05-01, Ralf Wildenhues [EMAIL PROTECTED] wrote:
Generally I think you should be able to just use it everywhere. The
Libtool testsuite uses it throughout and I cannot remember
On 2007-06-19, Peter O'Gorman [EMAIL PROTECTED] wrote:
I am inclined to vote for (1) for now. It might be worth a figuring out
how to have ldconfig (or some other utility) output the real search path
that the dynamic linker uses for the future, parsing ld.so.conf and
friends seems to be
[A somewhat belated reply, but I only just noticed this thread...]
On 2007-05-01, Ralf Wildenhues [EMAIL PROTECTED] wrote:
Generally I think you should be able to just use it everywhere. The
Libtool testsuite uses it throughout and I cannot remember a test
failure due to it. I'm however not
On 2006-11-28, Duft Markus [EMAIL PROTECTED] wrote:
If you could tell me how i can bring outlook to do so, i will gladly ;o)
Off-topic, but in the interests of improving the readability of this
list (and others!):
Outlook:
http://home.in.tum.de/~jain/software/outlook-quotefix/
Outlook
On 2007-03-05, Ralf Wildenhues [EMAIL PROTECTED] wrote:
As a workaround (that AFAICS won't break things in the future) you can put
m4_defun([_LT_AC_LANG_CXX_CONFIG])
m4_defun([_LT_AC_LANG_F77_CONFIG])
Neat. However to avoid problems with fussier bourne shells, I found that I
have to
With a fairly recent CVS HEAD libtool (but I see the same with 1.5.8)
the following command:
/bin/sh ../libtool --tag=CXX --mode=link g++ -o quartzcheck \
quartzcheck-quartzcheck.o ../testsuite/libbtreecheck.la ../libxapian.la
causes libtool to execute (my wrapping):
g++ -o
On Wed, May 17, 2006 at 07:19:57PM +0200, Ralf Wildenhues wrote:
At the same time let's get rid of the
CONFIGURE-AC argument we're suggesting there but which didn't work right
anyway. But let's not actually change the functionality, so that what
works continues to. (A bit fragile, I know; I
On 2006-05-17, Ralf Wildenhues [EMAIL PROTECTED] wrote:
Well, the point is that
autoreconf subdir/foobar.ac
simply won't cause the called tools to use foobar.ac, but the first that
exists in the list
subdir/configure.ac
subdir/configure.in
Yeah, I know.
My thought was that it is
[Cc:-ing Patrick, who originally hit this problem]
On Tue, May 16, 2006 at 07:58:28AM +0200, Ralf Wildenhues wrote:
* Olly Betts wrote on Tue, May 16, 2006 at 03:10:04AM CEST:
(I'm not totally sold on this approach - all those convenience libraries
take up a lot of space, and creating them
On 2006-05-16, Ralf Wildenhues [EMAIL PROTECTED] wrote:
Feel free, any kind of feedback is helpful. Esp. we're looking for
packages that are broken by the new Autoconf, so that unintended
incompatibilities can be fixed before the release.
I've tried it now. I didn't have to modify any of the
On Tue, May 16, 2006 at 01:03:43PM +0200, Ralf Wildenhues wrote:
* Olly Betts wrote on Tue, May 16, 2006 at 11:28:41AM CEST:
I've tried it now. I didn't have to modify any of the configure scripts
at all.
Any self-grown or third-party macros that use exit(3) in compile tests?
Not that I
On 2006-05-10, Ralf Wildenhues [EMAIL PROTECTED] wrote:
* Olly Betts wrote on Wed, May 10, 2006 at 04:38:08PM CEST:
Is there likely to be a 1.5.24 release soon?
Oh dear. Don't ask about my original plans. They were something like
this: have Autoconf-2.60 in March, then Libtool-1.5.24 soon
I'll apologise up front that this isn't the world's greatest bug report.
Unfortunately I don't have access to a viable cygwin platform for
testing this myself, so I just have end-user reports to go on.
My library currently builds by linking files in each directory into a
convenience library, and
On 2006-05-10, Ralf Wildenhues [EMAIL PROTECTED] wrote:
- there was actually a regression in 1.5.22 over 1.5.20 which caused
some paths to be incorrectly removed on FreeBSD and some other BSD
variants. Has since been fixed in CVS branch-1-5 (and HEAD).
Is there likely to be a 1.5.24
On 2006-04-30, Bob Rossi [EMAIL PROTECTED] wrote:
Unfortunatly, that doesn't work either.
test -z /progs || mkdir -p -- /progs
mkdir: cannot create directory `/progs': Permission denied
abs_top_builddir isn't set in the Makefile (with automake 1.8.5, and I
can't see a ChangeLog entry in 1.9.6
On Sun, Apr 30, 2006 at 08:18:34AM -0400, Bob Rossi wrote:
Is there any difference between using abs_top_builddir vs top_builddir?
The former has an absolute path, while the latter may not (in fact for
builddir I think it never will; for srcdir, the non-abs_ versions may
also in fact be
On 2006-02-24, Charles Wilson [EMAIL PROTECTED] wrote:
Olly Betts wrote:
I've only used it briefly once some time ago, and I can't remember
much about it. But if it does, then libtool should really depend on
file.
The official libtool package for cygwin (e.g. the one you get if you
select
On 2005-09-28, Jacob Meuser [EMAIL PROTECTED] wrote:
yes. I work with transcode (transcoding.org), which is a C program
that loads modules. some modules are written in C++. it works on
OpenBSD with the C++ modules linked to libstdc++. this is done
unconditionally in the Makefile.ams with
]
On 2005-09-27, Jacob Meuser [EMAIL PROTECTED] wrote:
On Mon, Sep 26, 2005 at 04:15:11PM +, Olly Betts wrote:
I did wonder about getting my project's configure to always specifying
-lstdc++ if the compiler if GCC (with: test $GXX = yes).
But I worry that I could end up trying to link
On 2005-09-22, Peter O'Gorman [EMAIL PROTECTED] wrote:
Do we know what the versions of the OS/gcc are where -lstdc++ is missing? We
can enplicitly add it (as we did recently for, I think, sunpro c++). Is this
a gcc bug, or is it by design?
I've only been able to test OpenBSD 3.7 with g++
On 2005-09-23, Ralf Wildenhues [EMAIL PROTECTED] wrote:
[ By the way, I don't think everyone in this discussion has subscribed
this list; if in doubt, speak up, or even better, set Mail-Followup-To:
next time ]
I'm following it on gmane, but an explicit Cc: isn't a problem.
* Jacob Meuser
On 2005-09-22, Ralf Wildenhues [EMAIL PROTECTED] wrote:
* Olly Betts wrote on Wed, Sep 21, 2005 at 11:00:30PM CEST:
The bottom line for me is that if I explicitly add -lstdc++ when
linking _xapian.so, it all works. If I don't, it doesn't. So I
kind of feel that ideally libtool should
On 2005-09-23, Peter O'Gorman [EMAIL PROTECTED] wrote:
I have no statistics for how many shared libraries are written in c++ but do
not take advantage of the standard c++ library, at a guess I'd say that the
majority use some libstdc++ features.
It's perhaps worth noting that not linking
On 2005-09-21, Peter O'Gorman [EMAIL PROTECTED] wrote:
IIRC, archive_cmds on openbsd does not use -nostdlib, so having empty
postdeps ought to be okay.
It looks like the problem is that g++ -shared doesn't link to libstdc++.
Here's the output from my original message (except wrapped for your
On Wed, Sep 21, 2005 at 05:05:53PM +0200, Ralf Wildenhues wrote:
Olly, can you show us the libtool link line that fails, plus the output
it generates (you can probably cut off after the first ten or so
errors to keep size down).
The libtool link doesn't fail. The failure comes when Python
On Wed, Sep 21, 2005 at 10:45:40PM +0200, Ralf Wildenhues wrote:
* Thorsten Glaser wrote on Wed, Sep 21, 2005 at 10:05:53PM CEST:
Olly Betts dixit:
It looks like the problem is that g++ -shared doesn't link to libstdc++.
gcc -shared creates a shared library.
On OpenBSD, shared
I'm trying to link C++ code into a shared object for use as a Python
module. I'm using libtool to do the linking. On Linux this works
well, but on OpenBSD it fails with lots of C++ library symbols not
found.
The problem seems to be that on OpenBSD the shared object doesn't
pull in libstdc++.
On Tue, Sep 20, 2005 at 01:30:37PM -0500, Bob Friesenhahn wrote:
On Tue, 20 Sep 2005, Olly Betts wrote:
I'm trying to link C++ code into a shared object for use as a Python
module. I'm using libtool to do the linking. On Linux this works
well, but on OpenBSD it fails with lots of C
On Tue, Sep 20, 2005 at 01:51:28PM -0500, Bob Friesenhahn wrote:
If you are using the C++ standard library, there are things going on
that you are normally blissfully unaware of. These may use static
initialization.
Fair enough, a C++ Python module may simply not work on some platforms.
But
On 2005-09-14, Ralf Wildenhues [EMAIL PROTECTED] wrote:
--- libltdl/argz.c1 Jun 2005 19:09:00 - 1.5
+++ libltdl/argz.c14 Sep 2005 15:56:38 -
@@ -29,6 +29,7 @@
/* Provide our wierdo HAVE_CONFIG_H rvalue for other clients. */
#if !defined(LTDL)
On Wed, Jun 01, 2005 at 09:16:38PM +0200, Ralf Wildenhues wrote:
* Olly Betts wrote on Sun, May 29, 2005 at 02:45:28AM CEST:
Patch against CVS HEAD.
Well, turns out that patch is against branch-1-5, [...]
Oops, you're right of course. I just used a CVS libtool tree I had
lying around from
I noticed the typo occured in a generated libtool script. It turns
out this has already been corrected in libtool CVS HEAD, but similar
typos exists elsewhere in libtool: occured in the documentation should
be occurred, and occurence in a code comment should be occurrence.
Patch against CVS
On Thu, Oct 11, 2001 at 09:24:15AM +1000, Kevin Ryde wrote:
Solaris 2.7 and HP-UX 10 don't think much of
rm -f
it provokes a bit of an error
rm: cannot remove `.' or `..'
This arises from libtool when compiling, I think due to $output_obj
being empty when -c -o
On Thu, Oct 11, 2001 at 09:57:18AM +1000, Kevin Ryde wrote:
Soor, I pruned too much, the libtool case is instead something like
rm -f foo.o
Ah right.
It's the empty argument which is the problem, not no arguments as
such.
I guess the quotes support spaces in filenames, it
David Lee writes:
(which particular case happens to be suitable for ESP's "epm" generic
package manager).
BTW, in case you aren't aware of it already, the Debian "Alien package
converter" may also be worth looking at for inspiration:
http://www.kitenet.net/programs/alien/
Cheers,
Olly
In message [EMAIL PROTECTED], Alexandre Oliva writes:
it's far easier to just install in a separate directory and have the
package manager collect them. This will work on *most* systems. On
some, it's necessary to have the libraries already installed in the
installation directory before you can
In message [EMAIL PROTECTED],
David Lee writes:
But the "big picture" is to be able to produce something along the lines of:
# Directories...
$prefix=/usr
[...]
# Installables
%system all
f 0555 root sys ${libdir}/libgdbm.so.2.0.0 .libs/libgdbm.so.2.0.0
l 0555 root sys
In message [EMAIL PROTECTED], stefan
writes:
since the MinGW32 (Minimal GNU for Windows) linker is able to create
shared libraries on Windows I would like to know if it would be posssible
to add support for DLLs to libtool ?
Libtool already can. There are a few things you need to do to get
In message [EMAIL PROTECTED], Greg Eisenhauer writes:
There is support for compiling with VC++ at least in the sense that cygpath
is called to fixup the source file names for the compiler. However, this
isn't done at the link stage and the path and file names embedded in the
*.la files are
In message [EMAIL PROTECTED], Alexandre Oliva writes:
[linking a library from other libraries with no object files]
The point is that this just can't be done portably.
Since libtool's major purpose is to allow libraries to be built using a
portable interface, perhaps it should take care of this
Hi,
I've been trying to use -export-symbols-regex with a C++ library, but the
way this feature currently works means that you get the mangled versions of
the symbols. This seems less than ideal for (at least) a couple of reasons:
* The mangled versions really are a cryptic implementation
54 matches
Mail list logo
