Re: [SCM] GNU Libtool branch, pr-msvc-support, updated. v2.2.6-182-gdd42e63
Den 2009-09-10 19:55 skrev Ralf Wildenhues: Hi Peter, * Peter Rosin wrote on Thu, Sep 10, 2009 at 10:06:32AM CEST: The branch, pr-msvc-support has been updated via dd42e63ce688302500f349606c55bf173feda3a4 (commit) [...] commit dd42e63ce688302500f349606c55bf173feda3a4 Merge: a128e6d5f8a57c0f3cfb85a28d8d843f504a3cdf b03736353b6d478a68bfc19c017605eb21a3edce Author: Peter Rosin p...@lysator.liu.se Date: Wed Sep 9 12:36:23 2009 +0200 Merge branch 'master' into pr-msvc-support Thank you! Ralf No problem, it was overdue anyway... But, I got this message when I made the push: warning: updating the current branch warning: Updating the currently checked out branch may cause confusion, warning: as the index and work tree do not reflect changes that are in HEAD. warning: As a result, you may see the changes you just pushed into it warning: reverted when you run 'git diff' over there, and you may want warning: to run 'git reset --hard' before starting to work to recover. warning: warning: You can set 'receive.denyCurrentBranch' configuration variable to warning: 'refuse' in the remote repository to forbid pushing into its warning: current branch. warning: To allow pushing into the current branch, you can set it to 'ignore'; warning: but this is not recommended unless you arranged to update its work warning: tree to match what you pushed in some other way. warning: warning: To squelch this message, you can set it to 'warn'. warning: warning: Note that the default will change in a future version of git warning: to refuse updating the current branch unless you have the warning: configuration variable set to either 'ignore' or 'warn'. So, it appears that the repo at savannah isn't bare and that pr-msvc-support is the currently checked out branch there? Or am I barking up the wrong tree? Cheers, Peter
Clean libconftest.a
Hi all,
this breaks distcheck on master.
From e1d61e869239cf37ac018602f984d52872a29203 Mon Sep 17 00:00:00 2001
From: Akim Demaille demai...@gostai.com
Date: Fri, 11 Sep 2009 13:14:29 +0200
Subject: [PATCH] libtool: clean libconftest.a.
* libltdl/m4/libtool.m4 (_LT_REQUIRED_DARWIN_CHECKS): Here.
---
libltdl/m4/libtool.m4 |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index 662a88b..8f0add8 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -991,7 +991,7 @@ _LT_EOF
else
cat conftest.err AS_MESSAGE_LOG_FD
fi
-rm -f conftest.err conftest.a conftest conftest.c
+rm -f conftest.err libconftest.a conftest conftest.c
rm -rf conftest.dSYM
])
case $host_os in
@@ -1137,7 +1137,7 @@ fi
# Invoke $ECHO with all args, space-separated.
func_echo_all ()
{
-$ECHO $*
+$ECHO $*
}
case $ECHO in
--
1.6.4.2
Re: Clean libconftest.a
Akim Demaille wrote: Hi all, this breaks distcheck on master. Hi Akim, Please push the first hunk (minus the whitespace change in func_echo_all). If you want to submit a whitespace patch, please do so separately. Thanks for catching this, Peter -- Peter O'Gorman http://pogma.com
Re: [SCM] GNU Libtool branch, pr-msvc-support, updated. v2.2.6-182-gdd42e63
Hello Jim, any chance you could check whether the Libtool git tree on savannah is non-bare? If yes, then we may want to fix that (but I'd have to check how to do that). See Peter's report below. Thanks, Ralf * Peter Rosin wrote on Fri, Sep 11, 2009 at 08:42:46AM CEST: Den 2009-09-10 19:55 skrev Ralf Wildenhues: * Peter Rosin wrote on Thu, Sep 10, 2009 at 10:06:32AM CEST: Merge branch 'master' into pr-msvc-support Thank you! Ralf No problem, it was overdue anyway... But, I got this message when I made the push: warning: updating the current branch warning: Updating the currently checked out branch may cause confusion, warning: as the index and work tree do not reflect changes that are in HEAD. warning: As a result, you may see the changes you just pushed into it warning: reverted when you run 'git diff' over there, and you may want warning: to run 'git reset --hard' before starting to work to recover. warning: warning: You can set 'receive.denyCurrentBranch' configuration variable to warning: 'refuse' in the remote repository to forbid pushing into its warning: current branch. warning: To allow pushing into the current branch, you can set it to 'ignore'; warning: but this is not recommended unless you arranged to update its work warning: tree to match what you pushed in some other way. warning: warning: To squelch this message, you can set it to 'warn'. warning: warning: Note that the default will change in a future version of git warning: to refuse updating the current branch unless you have the warning: configuration variable set to either 'ignore' or 'warn'. So, it appears that the repo at savannah isn't bare and that pr-msvc-support is the currently checked out branch there? Or am I barking up the wrong tree? Cheers, Peter
Re: [SCM] GNU Libtool branch, pr-msvc-support, updated. v2.2.6-182-gdd42e63
Ralf Wildenhues wrote: any chance you could check whether the Libtool git tree on savannah is non-bare? If yes, then we may want to fix that (but I'd have to check how to do that). See Peter's report below. Hi Ralf, It was indeed non-bare. git config core.bare reported false. I corrected that by running git config core.bare true.
RE: pr-msvc-support: building .DLLs with symbols
Here's a couple of patches that implements support for
-Wl, and -Xlinker for MSVC. The first one
(rename-dashL_envvar-tolinker_envvar.patch) is just a
rename, to reduce confusion, and the second patch
(-Xlinker-msvc.patch) contains the new code...
Ok for the pr-msvc-support branch?
I'm not sure I'm exercising the patch properly, but here's what I did:
- applied the patch
$ patch -p1 rename-dashL_envvar-tolinker_envvar.patch
$ patch -p1 -Xlinker-msvc.patch
- re-built libtool
$ cd build
$ make
$ make install
Then in one of my modules:
$ autoreconf -fvi
$ mkdir Debug
$ cd Debug
$ ../configure CC=cl CFLAGS='-MD -Zi' LD=link NM='dumpbin -symbols' AR=lib
STRIP=: RANLIB=: --disable-static
So far so good. But,
$ ../configure CC=cl CFLAGS='-MD -Zi' LD=link LDFLAGS='-Wl,-DEBUG'
NM='dumpbin -symbols' AR=lib STRIP=: RANLIB=: --disable-static
checking for a BSD-compatible install... /bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... cl
checking for C compiler default output file name...
configure: error: in `abs_path_to/build':
configure: error: C compiler cannot create executables
See `config.log' for more details.
and config.log has:
configure:2791: checking for C compiler default output file name
configure:2813: cl -MD -Zi -Wl,-DEBUG conftest.c 5
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for
80x86 Copyright (C) Microsoft Corporation. All rights reserved. cl :
Command line error D8021 : invalid numeric argument '/Wl,-DEBUG'
configure:2817: $? = 2
configure:2855: result:
configure: failed program was:
| /* confdefs.h. */
| #define PACKAGE_NAME foo
| #define PACKAGE_TARNAME foo
| #define PACKAGE_VERSION 1.0
| #define PACKAGE_STRING foo 1.0
| #define PACKAGE_BUGREPORT
| #define PACKAGE foo
| #define VERSION 1.0
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2861: error: in
`/c/utils/cygwin/home/dbyron/src/ams_svn/AMS_SDK/trunk/final_review/build':
configure:2864: error: C compiler cannot create executables
If I go back to the working configure invocation, but change my Makefile.am
with:
libfoo_la_LDFLAGS += -Wl,-DEBUG
The resulting library doesn't contain debug symbols. Here's the libtool
invocation that creates the library:
/bin/sh ./libtool --tag=CC --mode=link cl -MD -Zi -no-undefined
-export-symbols symfile -Wl,-DEBUG -o libfoo.la -rpath /usr/loca
l/lib libfoo_la-public.lo libfoo_la-private.lo
libtool: link: dumpbin -symbols .libs/libfoo_la-public.obj
.libs/libfoo_la-private.obj | gawk ' {last_section=section; sectio
n=$ 3}; /Section length .*#relocs.*(pick any)/{hide[last_section]=1};
$ 0!~/External *\|/{next}; / 0+ UNDEF /{next}; / U
NDEF \([^|]\)*()/{next}; {if(hide[section]) next}; {f=0}; $
0~/\(\).*\|/{f=1}; {printf f ? T : D }; {split($ 0, a,
/\||\r/); split(a[2], s)}; s[1]~/^...@?]/{print s[1], s[1]; next};
s[1]~prfx {split(s[1],t,@); print t[1], substr(t[1],lengt
h(prfx))} ' prfx=^_ | /bin/sed -e '/^[BCDGRS][ ]/s/.*[ ]\([^
]*\)/\1,DATA/' | /bin/sed -e '/^[AITW][ ]/s/.*[ ]//' | sort | uniq
.libs/foo.exp
libtool: link: if test x`/bin/sed 1q .libs/foo.def` = xEXPORTS; then sed
-n -e s/\\\(.*\\\)/-link\ -EXPORT:\\\1/ -e 1\!p .libs/f
oo.def .libs/foo-0.dll.exp; else sed -e s/\\\(.*\\\)/-link\ -EXPORT:\\\1/
.libs/foo.def .libs/foo-0.dll.exp; fi
libtool: link: cl -o .libs/foo-0.dll .libs/libfoo_la-public.obj
.libs/libfoo_la-private.obj -DEBUG@.libs/foo-0.dll.exp -link
-DLL
Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 14.00.50727.762 for
80x86
Copyright (C) Microsoft Corporation. All rights reserved.
cl : Command line warning D9035 : option 'o' has been deprecated and will be
removed in a future release
Microsoft (R) Incremental Linker Version 8.00.50727.762
Copyright (C) Microsoft Corporation. All rights reserved.
/out:libfoo_la-public.exe
/out:.libs/foo-0.dll
-DLL
.libs/libfoo_la-public.obj
.libs/libfoo_la-private.obj
Creating library .libs/foo-0.lib and object .libs/foo-0.exp
libtool: link: linknames=
libtool: link: rm -f .libs/foo.exp .libs/foo.filter
libtool: link: LINK=
libtool: link: ( cd .libs rm -f libfoo.la cp -p ../libfoo.la
libfoo.la )
Should I be doing something else?
-DB
Re: Clean libconftest.a
* Peter O'Gorman wrote on Fri, Sep 11, 2009 at 03:56:01PM CEST: Akim Demaille wrote: this breaks distcheck on master. Please push the first hunk (minus the whitespace change in func_echo_all). I just did that. Cheers, Ralf
Re: dynamically linking one of mysq, postgresql or sqlite3
On Fri, 11 Sep 2009, santilin wrote: Hi, I'm quite new to libtool though I have read the tree GNU manuals: automake, autoconf and libtool. I want to solve the typical problem of loading dinamically one of the sql servers drivers from my own shared library. I know I have to create a common interface for the drivers. What I am not sure is wheter I must use dlopen or there is any other way of loading the library. If I use dlopen, lets say, to open mysql.so, I have to read all the symbols and use pointers to them, which is a lot of work. I wonder if there is a way of loading the libraries the same way they are loaded when they are linked within the main program. I believe that you can use libltdl from libtool 2.X to do this by using lt_dlopenadvise() with the lt_dladvise_global option. This invokes dlopen() with the RTLD_GLOBAL flag. I don't recommend that you do this since it introduces ordering problems, is NOT PORTABLE, and does not solve the static linkage issue. If your code accidentally references a symbol before it is defined, then your program goes poof. If you design a common interface for the drivers, then you can use libltdl to locate just one symbol in the driver which is a registration function which registers all of the interface functions that the driver supports. You could pass a structure containing all of the possible function vectors and the driver module updates it, or you could have the module call back into your library (which it can do) and add itself as a driver. This is more efficient than using libltdl to search for all of the possible symbols (some of which may not exist). This allows all of the implementation functions (except for the registration function) to be 'static' since they don't require external visibility. Bob -- Bob Friesenhahn bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Trouble upgrading to 2.2.6a
Hello Alberto, Bob, * Alberto Luaces wrote on Tue, Sep 08, 2009 at 04:52:09PM CEST: On Martes, 8 de Septiembre de 2009 04:20:15 Bob Friesenhahn escribió: I have searched on the web and it seems that the problem is a mismatch with the libtool templates. However, I haven't been able to find any outdated template on my system: The outdated templates or files may be in your source tree. The only files present in my source tree are those three that I sent. Can any of the Autotools look in parent directories? Autotools only look in their own installation trees, or in the source tree at Makefile.am and below. Never above. Well, not really. libtoolize has if test -n $ac_auxdir; then # If $configure_ac contains AC_CONFIG_AUX_DIR, check that it was # not given in terms of a shell variable! [...] else # Try to discover auxdir the same way it is discovered by configure. # Note that we default to the current directory. for dir in . .. ../..; do if test -f $dir/install-sh; then [...] and the configure behavior mentioned in that comment is documented in 'info Autoconf Input'. Question is, whether the libtoolize behavior is desirable, and if so, then we should document it, and if not, we should change the code. If those files are not found, everything works well. If one of them is, then no ltmain.sh is copied and the building system is messed up. That is undesirable, but ought to be work-aroundable easily by using AC_CONFIG_AUX_DIR in configure.ac. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
