On Wed, Sep 19, 2001 at 07:58:14PM -0500, [EMAIL PROTECTED] wrote:
We've modified libtool.m4 to perfer shl_load on HP-UX *even* if dlopen
is available. The rationale for this is because dlopen() requires a
patch which all users might not have (we're running into this problem
now).
On Fri, 21 Sep 2001 [EMAIL PROTECTED] wrote:
On Thu, Sep 20, 2001 at 09:38:29PM -0500, Bob Friesenhahn wrote:
64-bit compilation under Solaris Sun's compiler requires that the
argument '-xarch=v9' be provided when compiling C++ objects.
Unfortunately libtool (1.4a (1.641.2.259 2001/06/04
From: Bob Friesenhahn [EMAIL PROTECTED]
On Fri, 21 Sep 2001 [EMAIL PROTECTED] wrote:
On Thu, Sep 20, 2001 at 09:38:29PM -0500, Bob Friesenhahn wrote:
64-bit compilation under Solaris Sun's compiler requires that the
argument '-xarch=v9' be provided when compiling C++ objects.
On Fri, 21 Sep 2001 [EMAIL PROTECTED] wrote:
The way Sun's build environment supports 64-bit compilation, it is
only necessary to build all objects using -xarch=v9. The linker is
responsible for selecting the correct mode based on the mode of the
objects. All linked objects must be
On Fri, Sep 21, 2001 at 12:33:22AM -0500, [EMAIL PROTECTED] wrote:
Does HEAD support *different* a different C and C++ compiler (e.g.
native vendor C and GNU C++)?
Well, HEAD passes all tests with AIX 4.3.2 and CC=xlc, CXX=g++. HP-UX
10.20 does not. Tru64 UNIX 4.0D with CC=cc, CXX=g++ works
On Sun, Sep 16, 2001 at 04:16:13PM +0200, Christoph Pfisterer wrote:
My submitted patch:
archive_cmds='$nonopt $(test .$module = .yes echo -bundle || echo -dynam
iclib) $allow_undefined_flag -o $lib $libobjs $deplibs$linker_flags
-install_nam
e $rpath/$soname $verstring'
After
At 19:18 Uhr +0100 21.09.2001, Gary V. Vaughan wrote:
On Sun, Sep 16, 2001 at 04:16:13PM +0200, Christoph Pfisterer wrote:
My submitted patch:
archive_cmds='$nonopt $(test .$module = .yes echo -bundle
|| echo -dynam
iclib) $allow_undefined_flag -o $lib $libobjs $deplibs$linker_flags
On Mon, Sep 17, 2001 at 02:00:14AM +0300, Tor Lillqvist wrote:
This fixes a problem on Cygwin (with the Mingw gcc, even if I doubt it
matters here) where invoking libtool --mode=install fails to install
exes. The libtool command line refers to progname.exe, while the
wrapper script that
Hi there,
two problems with libtool HEAD-cvs:
1) with regard to dlpreopen, there is yet another quoting problem.
The libtool file generated from HEAD-cvs contains three lines like
this:
global_symbol_to_c_name_address=sed -n -e 's/^: \([^ ]*\) \$/
{\\\1\\, (lt_ptr) 0},/p' -e 's/^[BCDEGRST]
I am running autoconf-2.52, automake-1.5, and
libtool-1.4b.
On IRIX64-6.5 using CC and passing -version-info 0:0:0
to libtool I get
-rwxr-xr-x1 ironst pfix 763 Sep 20 18:43 libView.la*
lrwxrwxr-x 1 ironst pfix 15 Sep 20 18:43 libView.so - libView.so..1.0*
Here is an eg of the error message I get:
1415148:./testSim: rld: Fatal Error: Cannot Successfully map soname 'libView.so..1'
under any of the filenames
At 1:35 Uhr +0200 22.09.2001, Max Horn wrote:
[...]
2) in libtool.m4, HEAD cvs, line 4685, look like this:
_LT_AC_TAGVAR(whole_archive_flag_spec, $1)='-all_load $convenience'
This particular line, as I know realize, is the source of various
problem I have with libtool on darwin. It
I'm cross-posting this to the autoconf and libtool lists, because I'm not
sure whose jurisdiction this is.
I accidentally found this while trying to compile libxml2-2.4.5 under Solaris.
I say accidentally because was compiling without /usr/local/lib in my
$LD_LIBRARY_PATH, which was probably
On Fri, Sep 21, 2001 at 02:57:21PM -0500, Kenneth Pronovici wrote:
I'm cross-posting this to the autoconf and libtool lists, because I'm not
sure whose jurisdiction this is.
I accidentally found this while trying to compile libxml2-2.4.5 under Solaris.
I say accidentally because was
From: Tim Van Holder [EMAIL PROTECTED]
Date: Fri, 21 Sep 2001 18:44:43 +0200
bash's behaviour with regards to the 'set' builtin has changed in 2.05
This apparently lead to a broken config.cache when using bash 2.05
! ac_cv_path_install=${ac_cv_path_install='ginstall -c'}
---
I asked about this a whil ago, but since I didn't receive any
comments, I'm asking again.
bash's behaviour with regards to the 'set' builtin has changed
in 2.05:
3. New Features in Bash
b. When `set' is called without options, it prints function
defintions in a way that allows them
16 matches
Mail list logo