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
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 +0000, 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
>> >
[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
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 f
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 Expre
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 d
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 .libs/quartzcheck
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 i
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;
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
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
[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
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 t
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 Autocon
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 r
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 absolute
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
On 2006-04-13, Olly Betts <[EMAIL PROTECTED]> wrote:
> On 2006-04-13, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
>> Except for the small design bug with execute mode, that if
>> you have the installed module dir as RPATH, then it's system-dependent
>> whet
On 2006-04-13, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * Olly Betts wrote on Thu, Apr 13, 2006 at 05:29:26PM CEST:
>> I realise that there is in general (both for libraries and modules), but
>> when building modules for a particular application that is known not to
>&g
On 2006-04-13, Alexandre Duret-Lutz <[EMAIL PROTECTED]> wrote:
> Olly Betts:
>| phpextdir = `$(PHP_CONFIG) --extension-dir`
>| phpext_LTLIBRARIES = php_mod_bt.la
>
> Unless `php-config --extension-dir` returns something like
> $(prefix)/foo/bar, this setup will prevent non-
On 2006-04-13, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * Olly Betts wrote on Thu, Apr 13, 2006 at 12:53:53AM CEST:
>>
>> phpextdir = `$(PHP_CONFIG) --extension-dir`
>> phpext_LTLIBRARIES = php_mod_bt.la
>>
>> You probably also want to remove the .la
On 2006-04-12, Tyler MacDonald <[EMAIL PROTECTED]> wrote:
> I'm trying to ion-diret automake/libtool to allow me to install a library into
> PHP's extension directory.
phpextdir = `$(PHP_CONFIG) --extension-dir`
phpext_LTLIBRARIES = php_mod_bt.la
You probably also want to remove the .la file this
On 2006-03-29, Brian Gough <[EMAIL PROTECTED]> wrote:
> checking for ar... false
> [...]
> false cru .libs/libutils.a .libs/placeholder.o
> make[2]: *** [libutils.la] Error 1
If AR defaulted to "$(MISSING) ar" if no ar was found (instead of false), then
no error is given if ar is not found b
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
On 2006-02-18, Brian Dessent <[EMAIL PROTECTED]> wrote:
> If libtool currently displays somewhat degraded or broken behavior
> without 'file'
Currently it's somewhat broken, but it sounds like it'll be patched at
some point and become somewhat degraded.
> then it would be a good idea to at least
On 2006-01-05, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> * ltmain.in (link mode): Disregard
> `hardcode_libdir_flag_spec_ld' if we're using `$CC' to link.
> * libtool.m4 () [ hpux10, hpux11; hppa*64*, ia64* ]
> : Removed.
> Reported by Roger While <[EMAIL
On Tue, Feb 14, 2006 at 08:12:58PM -0600, Bob Friesenhahn wrote:
> On Tue, 14 Feb 2006, Ralf Wildenhues wrote:
> >* Olly Betts wrote on Tue, Feb 14, 2006 at 08:06:52PM CET:
> >>I tried to search for previous references to this issue, but it's pretty
> >>much i
I tried to search for previous references to this issue, but it's pretty much
impossible to usefully search for "file"! Sorry if this is rehashing old
discussions.
A user reported a problem trying to build my libtool-ed project on cygwin.
The problem turned out to be that cygwin apparently doesn'
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 w
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++ 3
.libtool.general/6671
]
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 &
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 l
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.
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 Meus
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
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 t
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 yo
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.
B
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
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++. Py
On Thu, Oct 25, 2001 at 02:43:23PM -0500, Robert Boehne wrote:
> + if test `expr "X$rmfiles" : ".*"` -gt $max_cmd_len; then
How portable is "test -gt"? The Goat book doesn't list it as a portable
test operator:
http://sources.redhat.com/autobook/autobook/autobook_216.html
Cheers,
Olly
__
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 filename
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
On Wed, Jun 20, 2001 at 03:23:18AM +0200, Guido Draheim wrote:
> What is HOST_CC ? It has no default, and cross-gcc is the wrong cc.
It's meant to point to a native compiler in precisely this situation to
solve the problem of impgen getting cross-compiled and so being useless.
> Did now try with
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 yo
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
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 g
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
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 detail
53 matches
Mail list logo
