RE: Subject: [libtool 2.1c] testsuite: 44 45 46 failed

[Duft Markus]

Duft Markus <> wrote:
> Ralf Wildenhues  wrote:
>> You have several options to avoid this failure:
>> 
>> - find out why timestamps are not in the right order after   
>> libtoolize --ltdl=sub/ltdl 
>> 
>> (inside sub/ltdl, configure.ac should come before aclocal.m4 should
>> come before configure and Makefile.in).  This is a bug.  It seems
>> that has to do with your system's symlink semantics.
>> 
>> - upgrade to Automake 1.10 locally (your automake 1.9.6 gets run
>> accidentally by the test due to above timestamp messup.  This is
>> because having a toplevel package
>> 
>> - Fix your local automake 1.9.6 installation by using this patch:
>> 
>

>> 
> 
> Ok Thanks. I will have a look at this. For Symlinks: i use cp -p
> instead of ln -s. can this cause the misbehaviour?
> 
> For Automake: i have gentoo/alt-prefix portage installed as system, so
> i'm using whatever a corresponding linux for example would use. I now
> double checked, but it seems i have only one automake installed:
> 
> These are the packages that would be merged, in order:
> 
> Calculating dependencies... done!
> [ebuild   R   ] sys-devel/automake-1.10  0 kB
> 
> Total: 1 package (1 reinstall), Size of downloads: 0 kB
> mduft build.libtool $ type automake
> automake is /opt/gentoo/usr/bin/automake
> mduft build.libtool $
> 
> As for the patch for 1.9.6: i cannot find a 1.9.6 installation here. I
> will try and rebootstrap everything, but i have done this before
> running the testsuite as far as i remember

Hi!

This has to be a problem of every gentoo linux or gentoo/alt-prefix
installation on any host system: automake is a link to am-wrapper.sh
which in turn looks at Makefile.in to find out which version of automake
to use. If there is no Makefile.in it uses the newest (1.10)  Arg.
This means, that it will allways use 1.9.6 here, until 1.9.6 is
uninstalled from the system (yes i missed it before, it _is_ installed
of course...).

So of course this is not a libtool bug. I will talk to gentoo guys to
further follow this. Thanks for the help so far.

Cheers, Markus

> 
> Cheers, Markus
> 
>> Cheers,
>> Ralf
> 
> 
> 
> ___
> http://lists.gnu.org/mailman/listinfo/libtool



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Solaris 10 w/ SunStudio 11 64bit mode

[Tim Rice]

Hi Ralf,

On Mon, 11 Feb 2008, Ralf Wildenhues wrote:
> * Tim Rice wrote on Mon, Feb 11, 2008 at 06:23:59AM CET:
> > CVS HEAD pulled Fri Feb  8 17:52:22 PST 2008
> > Solaris 10 w/ SunStudio 11
> > 
> > I'm seeing failures in 64 bit mode I don't see in 32 bit mode with
> > compiler options that woked for me in both 32 & 64 on branch-1.5.
> > testsuite.log-64.gz attached.
> 
> Please try again, with making the f95 compiler generate 64bit code:
>   FCFLAGS="-xtarget=ultra -xarch=v9"
> 
> assuming those are the right options.  $FFLAGS is for $F77, $FCFLAGS is
> for $FC, and needed in this case.  (Libtool currently doesn't support
> having two different-language compilers do different ABIs.)

I didn't expect it to work with diifferent ABIs I thought I had what I
needed with FFLAGS="-xtarget=ultra -xarch=v9"
Thanks for the FCFLAGS tip, that worked.

Tests pass now.

-- 
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]




___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Libtool 2.1b test results

[Ralf Wildenhues]

* Ralf Wildenhues wrote on Sat, Feb 09, 2008 at 09:22:19AM CET:
> * Mike Frysinger wrote on Sat, Feb 09, 2008 at 08:37:31AM CET:
> 
> > # Whether or not to optimize for fast installation.
> > fast_install=needless
> 
> This looks very weird to me, and I cannot explain it at all.  Did you use
> any patches on top of 2.1b?  You didn't `./configure --disable-shared'
> either.  And shlibpath_overrides_runpath is no, too.

Can you try to find out why this happens for you?  Either put 'set -x'
as second line in the configure script, or embrace the code regions that
set enable_fast_install with 'set -x'/'set +x', and post the (gziped,
please) output.

Thanks,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

cygwin: module naming and soname_spec gobbledygook

[paul ヽ]

on cygwin, modules (explicitly with -module -avoid-version) with an install 
name such as libfoo.la get messed up by soname_spec and have their dynamic link 
library installed as cygfoo.dll (at least with libtool-1.5.26)

my key issue being if you were to install libxml2 with python bindings on 
cygwin, it's libxml2mod.la gets installed as libxml2mod.a libxml2mod.dll.a and 
cygxml2mod.dll, and this misnaming/renaming of the dynamic module prevents 
python from loading it as any reference to it in any python file is 'libxml2mod'


_
Shed those extra pounds with MSN and The Biggest Loser!
http://biggestloser.msn.com/




___
Bug-libtool mailing list
[EMAIL PROTECTED]
http://lists.gnu.org/mailman/listinfo/bug-libtool

Re: MacOS X 10.5 and -export-symbols-regex

[Peter O'Gorman]

Joe Orton wrote:
> We've had a report for Apache httpd that use of -export-symbols-regex is 
> causing the produced DSO to be unusable with OS X 10.5.1.  This was with 
> libtool 1.5.22:
> 
> http://issues.apache.org/bugzilla/show_bug.cgi?id=44384
> 
> I've CC'ed Giuliano, the reporter.  Can anybody help?  The module in 
> question, mod_ssl, is linked using
> 
>-module -avoid-version ... -export-symbols-regex ssl_module
> 
> (to avoid exporting anything other than the DSO entry point)
> 

(Still waiting for bugzilla password to arrive - will paste this into
the bug when it does).

I have had other reports of this, and changed libtool in 1.5.26 and HEAD
to use ld's  -exported_symbols_list flag if it is available, instead of
a separate invocation of nmedit. In one case this fixed the problem.

I have not had time to reproduce on my own system to gather enough
information to file a bug with Apple - a trivial test case I tried a
month or two ago worked fine with nmedit being used to limit the
exported symbols.

I will try to find the time to investigate, in the meantime, either
remove the exported symbol limiting on darwin (ugh.) or try with latest
libtool-1.5.26.

Peter
-- 
Peter O'Gorman
http://pogma.com


___
http://lists.gnu.org/mailman/listinfo/libtool

RE: Subversion debugging continued

[[EMAIL PROTECTED]]

Replying to my own mail, as I have now pinned down the error.

I changed the

#!/usr/bin/python

in the scripts to

#!/usr/bin/sparcv9/python

And it now works.


Thanks again folks

So long,
Igor


mail2web.com – What can On Demand Business Solutions do for you?
http://link.mail2web.com/Business/SharePoint




___
http://lists.gnu.org/mailman/listinfo/libtool

Subversion debugging continued

[[EMAIL PROTECTED]]

Some time ago I asked for help to build Subversion on Solaris 10, Sparc 64
with Sun 
Studio 12, because I was getting errors of the kind: "wrong ELF class:
ELFCLASS64", when 
linking swig-py bindings.


Now I managed to build the package:

export CC=cc64
export CXX=CC64

export CFLAGS="${CFLAGS} -mt"
export CXXFLAGS=${CFLAGS}
export 
LDFLAGS="${LDFLAGS} -L${_prefix}/lib -R${_prefix}/lib -L/usr/sfw/lib/64
-R/usr/sfw/lib/64 -lcrypto_extra -lssl_extra"
export PYTHON=python2.4
export JAVA_HOME=/opt/appserv/java
export JAVA=/opt/appserv/java/bin/sparcv9/java

/configure --prefix=${_prefix} --localstatedir=${_localstd}/${pkgname} \
--with-apr=${_prefix} --with-apr-util=${_prefix} --with-zlib=/usr \
--with-swig=${_prefix} --with-neon=${_prefix} --with-ssl
--enable-ssl \
--with-apxs=${_prefix}/bin/apxs --enable-javahl
--with-jdk=/opt/appserv/java &&
${MAKE} &&
${MAKE} LT_LDFLAGS="-$Fdestdir${_prefix}/lib" local-all &&
export
LD_LIBRARY_PATH=${_basedir}/${pkgname}/staging/${pkgname}-${pkgver}/opt/baw/
lib:
$LD_LIBRARY_PATH &&
${MAKE} DESTDIR=${_basedir}/${pkgname}/staging/${pkgname}-${pkgver} install
&&


${MAKE} DESTDIR=${_basedir}/${pkgname}/staging/${pkgname}-${pkgver} swig-py
&&
${MAKE} DESTDIR=${_basedir}/${pkgname}/staging/${pkgname}-${pkgver}
install-swig-py &&

${MAKE} DESTDIR=${_basedir}/${pkgname}/staging/${pkgname}-${pkgver} javahl
&&
${MAKE} DESTDIR=${_basedir}/${pkgname}/staging/${pkgname}-${pkgver}
install-javahl



But this seems to have only shifted the problem from link-time execution
time, giving 
me:

[Fri Feb 08 15:50:47 2008] [error] [client 10.80.14.40] Could not MERGE 
resource "/svn/testr/!svn/act/b7afb3a7-b92a-964a-bf62-8e5fc9820fa7" 
into "/svn/testr/trunk".  [409, #0]
[Fri Feb 08 15:50:47 2008] [error] [client 10.80.14.40] An error occurred
while 
committing the transaction.  [409, #165001]
[Fri Feb 08 15:50:47 2008] [error] [client 10.80.14.40] 'pre-commit' hook
failed with 
error output:\nPlease provide some text in log message\nTraceback (most
recent call 
last):\n  File
"/var/bldserv/svn/repos/testr/hooks/check-case-insensitive.py", line 64, 
in ?\nfrom svn import fs, core, repos, delta\n  
File "/opt/baw/lib/svn-python/svn/fs.py", line 19, in ?\nfrom libsvn.fs
import *\n  
File "/opt/baw/lib/svn-python/libsvn/fs.py", line 5, in ?\nimport
_fs\nImportError: 
ld.so.1: python2.4: fatal: /opt/baw/lib/svn-python/libsvn/_fs.so: wrong ELF
class: 
ELFCLASS64\n  [409, #165001]


Which is essentiall the same error: "wrong ELF class: ELFCLASS64"

Here's an ldd of the offending file:

libsvn_swig_py-1.so.0 => /opt/baw/lib/libsvn_swig_py-1.so.0
libsvn_fs-1.so.0 =>  /opt/baw/lib/libsvn_fs-1.so.0
libsvn_subr-1.so.0 =>/opt/baw/lib/libsvn_subr-1.so.0
libsocket.so.1 =>/lib/sparcv9/libsocket.so.1
libz.so.1 => /usr/lib/sparcv9/libz.so.1
libc.so.1 => /lib/sparcv9/libc.so.1
libcrypto_extra.so.0.9.7 => 
/usr/sfw/lib/sparcv9/libcrypto_extra.so.0.9.7
libssl_extra.so.0.9.7 =>
/usr/sfw/lib/sparcv9/libssl_extra.so.0.9.7
libsvn_client-1.so.0 =>  /opt/baw/lib/libsvn_client-1.so.0
libsvn_delta-1.so.0 =>   /opt/baw/lib/libsvn_delta-1.so.0
libsvn_wc-1.so.0 =>  /opt/baw/lib/libsvn_wc-1.so.0
libaprutil.so.0 =>   /opt/baw/lib/libaprutil.so.0
libldap.so.5 =>  /usr/lib/sparcv9/libldap.so.5
libdl.so.1 =>/lib/sparcv9/libdl.so.1
libexpat.so.0 => /usr/sfw/lib/sparcv9/libexpat.so.0
libapr-1.so.0 => /opt/baw/lib/libapr-1.so.0
libuuid.so.1 =>  /lib/sparcv9/libuuid.so.1
libsendfile.so.1 =>  /lib/sparcv9/libsendfile.so.1
librt.so.1 =>/lib/sparcv9/librt.so.1
libnsl.so.1 =>   /lib/sparcv9/libnsl.so.1
libpthread.so.1 =>   /lib/sparcv9/libpthread.so.1
libsvn_fs_fs-1.so.0 =>   /opt/baw/lib/libsvn_fs_fs-1.so.0
libcrypto.so.0.9.7 =>/usr/sfw/lib/sparcv9/libcrypto.so.0.9.7
libssl.so.0.9.7 =>   /usr/sfw/lib/sparcv9/libssl.so.0.9.7
libsvn_ra-1.so.0 =>  /opt/baw/lib/libsvn_ra-1.so.0
libsvn_diff-1.so.0 =>/opt/baw/lib/libsvn_diff-1.so.0
libsasl.so.1 =>  /usr/lib/64/libsasl.so.1
libmd.so.1 =>/lib/64/libmd.so.1
libnspr4.so =>   /usr/lib/mps/64/libnspr4.so
libplc4.so =>/usr/lib/mps/64/libplc4.so
libnss3.so =>/usr/lib/mps/64/libnss3.so
libssl3.so =>/usr/lib/mps/64/libssl3.so
libaio.so.1 =>   /lib/64/libaio.so.1
libmp.so.2 =>/lib/64/libmp.so.2
libscf.so.1 =>   /lib/64/libscf.so.1
libsvn_ra_local-1.so.0 =>/opt/baw/lib/libsvn_ra_local-1.so.0
libsvn_repos-1.so.0 =>   /opt/baw/lib/libsvn_repos-1.so.0
libsvn_ra_svn-1.so.0 =>  /opt/baw/lib/libsvn_ra_svn-1.so.0
libsvn_ra_dav-1.so.0 =>  /opt/baw/lib/libsvn_ra_dav-1.so.0
libthread.so.1 =>/lib/64/libthread.so.1
libsof

RE: Subject: [libtool 2.1c] testsuite: 44 45 46 failed

[Duft Markus]

Ralf Wildenhues  wrote:
> You have several options to avoid this failure:
> 
> - find out why timestamps are not in the right order after
>libtoolize --ltdl=sub/ltdl
> 
> (inside sub/ltdl, configure.ac should come before aclocal.m4 should
> come before configure and Makefile.in).  This is a bug.  It seems
> that has to do with your system's symlink semantics.
> 
> - upgrade to Automake 1.10 locally (your automake 1.9.6 gets run
> accidentally by the test due to above timestamp messup.  This is
> because having a toplevel package
> 
> - Fix your local automake 1.9.6 installation by using this patch:
>

> 

Ok Thanks. I will have a look at this. For Symlinks: i use cp -p instead
of ln -s. can this cause the misbehaviour?

For Automake: i have gentoo/alt-prefix portage installed as system, so
i'm using whatever a corresponding linux for example would use. I now
double checked, but it seems i have only one automake installed:

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild   R   ] sys-devel/automake-1.10  0 kB

Total: 1 package (1 reinstall), Size of downloads: 0 kB
mduft build.libtool $ type automake
automake is /opt/gentoo/usr/bin/automake
mduft build.libtool $

As for the patch for 1.9.6: i cannot find a 1.9.6 installation here. I
will try and rebootstrap everything, but i have done this before running
the testsuite as far as i remember

Cheers, Markus

> Cheers,
> Ralf



___
http://lists.gnu.org/mailman/listinfo/libtool

RE: Subject: [libtool 2.1c] testsuite: 44 45 46 failed

[Duft Markus]

Duft Markus <> wrote:
> Ralf Wildenhues  wrote:
>> 
>> Thanks, I forgot about the need to 'make install' first.
>> 
>> Does ls have an option to show full time stamp resolution?  If yes,
>> please repeat the above after 'rm -rf t', using the option with both
>> ls invocations.
> 
> Ok, i added --full-time. In the meantime i found something in
> sub/ltdl/Makefile. The rule for distdir is:
> 
> 704 distdir: $(DISTFILES)
> 705 $(am__remove_distdir)
> 706 mkdir $(distdir)
> 
> The mkdir fails because the directory allready exists... I'll dig
> deeper there.
> 

Seems i found it: the distdir rule in the top level makefile looks a
little different:

472 distdir: $(DISTFILES)
473 $(am__remove_distdir)
474 test -d $(distdir) || mkdir $(distdir)

Shouldn't the one in sub/ltdl look the same? When adding the test -d
there, make dist runs through without error.

Cheers, Markus

> 
>> 
>> Cheers,
>> Ralf



___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Subject: [libtool 2.1c] testsuite: 44 45 46 failed

[Ralf Wildenhues]

You have several options to avoid this failure:

- find out why timestamps are not in the right order after
   libtoolize --ltdl=sub/ltdl

(inside sub/ltdl, configure.ac should come before aclocal.m4 should come
before configure and Makefile.in).  This is a bug.  It seems that has to
do with your system's symlink semantics.

- upgrade to Automake 1.10 locally (your automake 1.9.6 gets run
accidentally by the test due to above timestamp messup.  This is
because having a toplevel package 

- Fix your local automake 1.9.6 installation by using this patch:


Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

RE: Subject: [libtool 2.1c] testsuite: 44 45 46 failed

[Duft Markus]

Ralf Wildenhues  wrote:
> 
> Thanks, I forgot about the need to 'make install' first.
> 
> Does ls have an option to show full time stamp resolution?  If yes,
> please repeat the above after 'rm -rf t', using the option with both
> ls invocations.

Ok, i added --full-time. In the meantime i found something in
sub/ltdl/Makefile. The rule for distdir is:

704 distdir: $(DISTFILES)
705 $(am__remove_distdir)
706 mkdir $(distdir)

The mkdir fails because the directory allready exists... I'll dig deeper
there.

Cheers, Markus

> 
> Cheers,
> Ralf



log-interix1.gz
Description: log-interix1.gz
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Subject: [libtool 2.1c] testsuite: 44 45 46 failed

[Ralf Wildenhues]

* Duft Markus wrote on Mon, Feb 11, 2008 at 09:11:01AM CET:
> Ralf Wildenhues  wrote:
> > Please enter the top build directory, execute these commands, and post
> > log-interix1.gz:
> > 
> > ( mkdir t
> > cd t
> > ../libtoolize --copy --ltdl=sub/ltdl
> > ls -lart sub/ltdl
> > rm -rf sub
> > ../libtoolize --ltdl=sub/ltdl
> > ls -lart sub/ltdl
> > cd ../tests/testsuite.dir/44
> > head Makefile.in configure sub/ltdl/Makefile.in sub/ltdl/configure
> > make -n distdir
> > ) 2>&1 | tee log-interix1
> > gzip log-interix1

> Since the commands reported errors/warnings at first, i did a gmake
> install before repeating. I attached both logs.

Thanks, I forgot about the need to 'make install' first.

Does ls have an option to show full time stamp resolution?  If yes,
please repeat the above after 'rm -rf t', using the option with both ls
invocations.

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

RE: Subject: [libtool 2.1c] testsuite: 44 45 46 failed

[Duft Markus]

Ralf Wildenhues  wrote:
> Please enter the top build directory, execute these commands, and post
> log-interix1.gz:
> 
> ( mkdir t
> cd t
> ../libtoolize --copy --ltdl=sub/ltdl
> ls -lart sub/ltdl
> rm -rf sub
> ../libtoolize --ltdl=sub/ltdl
> ls -lart sub/ltdl
> cd ../tests/testsuite.dir/44
> head Makefile.in configure sub/ltdl/Makefile.in sub/ltdl/configure
> make -n distdir
> ) 2>&1 | tee log-interix1
> gzip log-interix1

Hi Ralf!

Since the commands reported errors/warnings at first, i did a gmake
install before repeating. I attached both logs.

Cheers, Markus

> 
> Thanks,
> Ralf



log-interix.tgz
Description: log-interix.tgz
___
http://lists.gnu.org/mailman/listinfo/libtool

Re: Subject: [libtool 2.1c] testsuite: 44 45 46 failed

[Ralf Wildenhues]

[ cutting libtool-patches ]

* Duft Markus wrote on Mon, Feb 11, 2008 at 08:28:50AM CET:
> 
> I have ported (again) libtool to windows using parity. No I'm stuck with
> the last three testsuite failures, which I just can't find causes for...

Please enter the top build directory, execute these commands, and post
log-interix1.gz:

( mkdir t
cd t
../libtoolize --copy --ltdl=sub/ltdl
ls -lart sub/ltdl
rm -rf sub
../libtoolize --ltdl=sub/ltdl
ls -lart sub/ltdl
cd ../tests/testsuite.dir/44
head Makefile.in configure sub/ltdl/Makefile.in sub/ltdl/configure
make -n distdir
) 2>&1 | tee log-interix1
gzip log-interix1

Thanks,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool

MacOS X 10.5 and -export-symbols-regex

[Joe Orton]

We've had a report for Apache httpd that use of -export-symbols-regex is 
causing the produced DSO to be unusable with OS X 10.5.1.  This was with 
libtool 1.5.22:

http://issues.apache.org/bugzilla/show_bug.cgi?id=44384

I've CC'ed Giuliano, the reporter.  Can anybody help?  The module in 
question, mod_ssl, is linked using

   -module -avoid-version ... -export-symbols-regex ssl_module

(to avoid exporting anything other than the DSO entry point)

Regards,

joe


___
http://lists.gnu.org/mailman/listinfo/libtool

RE: Subject: [libtool 2.1c] testsuite: 44 45 46 failed

[Duft Markus]

Duft Markus <> wrote:
> Ralf Wildenhues  wrote:
> 
> Hi Ralf!
> 
> Since the commands reported errors/warnings at first, i did a gmake
> install before repeating. I attached both logs.

Hi!

I finally found the real error :) Seems i was just to blind to see... It
seems to be related to the gmake dist call:

mduft 44 $ rm -rf subproject-demo-2.1c/
mduft 44 $ gmake dist
{ test ! -d subproject-demo-2.1c || { find subproject-demo-2.1c -type d
! -perm -200 -exec chmod u+w {} ';' && rm -fr subproject-demo-2.1c; }; }
test -d subproject-demo-2.1c || mkdir subproject-demo-2.1c
list='sub/ltdl'; for subdir in $list; do \
  if test "$subdir" = .; then :; else \
test -d "subproject-demo-2.1c/$subdir" \
|| /opt/gentoo/bin/mkdir -p "subproject-demo-2.1c/$subdir" \
|| exit 1; \
distdir=`CDPATH="${ZSH_VERSION+.}:" && cd
subproject-demo-2.1c && pwd`; \
top_distdir=`CDPATH="${ZSH_VERSION+.}:" && cd
subproject-demo-2.1c && pwd`; \
(cd $subdir && \
  gmake  \
top_distdir="$top_distdir" \
distdir="$distdir/$subdir" \
am__remove_distdir=: \
am__skip_length_check=: \
distdir) \
  || exit 1; \
  fi; \
done
gmake[1]: Entering directory
`/home/mduft/parity/build.libtool/tests/testsuite.dir/44/sub/ltdl'
:
mkdir
/home/mduft/parity/build.libtool/tests/testsuite.dir/44/subproject-demo-
2.1c/sub/ltdl
mkdir: cannot create directory
`/home/mduft/parity/build.libtool/tests/testsuite.dir/44/subproject-demo
-2.1c/sub/ltdl': File exists
gmake[1]: *** [distdir] Error 1
gmake[1]: Leaving directory
`/home/mduft/parity/build.libtool/tests/testsuite.dir/44/sub/ltdl'
gmake: *** [distdir] Error 1

Cheers, Markus
> 
>> 
>> Thanks,
>> Ralf



___
http://lists.gnu.org/mailman/listinfo/libtool