Re: [Autoconf] Re: Libtool warning message
Hello, Gary and Bob! > > checking whether a program can dlopen itself... cat: cannot open conftest.cc > > no > > This looks like a problem in AC_TRY_RUN from cvs autoconf to me. Are Words "dlopen itself" come from ltconfig.in. If you look around those words, you will find an excellent example of a wrong assumption: cat > conftest.c < conftest.c < conftest.$ac_ext < conftest.c < conftest.$ac_ext < To be sure, could you try it again with autoconf-2.13 and see whether > it goes away, please? Yes, it does. Which means that ltconfig is run with the C language active when Autoconf-2.13 is used. For Autoconf-2.49a the current language is C++. I tried this on libtool itself. I don't know what language should be active when ltconfig is run. However, if you search for "sco3.2v5" in libtool.m4 you will find an explicit AC_LANG_C in AC_LIBTOOL_SETUP, which _probably_ means that running ltconfig in the C++ mode is not ruled out. Otherwise, you need a check in ltconfig.in that the current language is C and nothing else. You may also need to use AC_LANG_C not only for "sco3.2v5" Regards, Pavel Roskin
Naming a project gnu-win32?
Hello, An issue has recently been raised (by me) in the libtool mailing list regarding the desirability of using the label "gnu-win32" in scripts like libtool (and, I presume, configure). I seem to recall that you have an objection to linking the name "GNU" to something like "win32" because the "win" part makes it seem like the user is "winning" with a proprietary OS. Or, at any rate, this is the aprocryphal story that I heard when I started working on the Cygwin project. This is what prompted the name change from gnu-win32 to cygwin32, or at least that is what I was told. Anyway, there is now a new, unrelated project now that is billing itself as "gnu-win32" and I thought it might be a good idea to alert you to this before the name started popping up in configure and libtool scripts. We also have made the switch from cygwin32 to cygwin due to the possibility that Microsoft would sue for trademark infringement on the name "win32" (sigh). But that's probably a separate issue... -Christopher Faylor
Re: Re[2]: Support pw32 as gnu-win32 target
On Fri, Sep 15, 2000 at 08:22:21PM +0100, Gary V. Vaughan wrote: >> But my original patch (hm, below) would allow to save sensibility >> for something more useful. Don't provide excess configurability when >> it's hardly needed. > >But it is. Chris Faylor has specifically denounced the cygfoo.dll >convention, but Chuck Wilson (and presumably yourself) would like an >option to use it for your own ports. It is also more general, rather >than adding a bunch more special cases to libtool, porters can add >'-soname cygfoo.dll' to foo_LDFLAGS if they wish. That, I like. I have no problem with people who contribute DLLs for cygwin establishing a "cyg*.dll" standard but I'd rather not make it the default for libtool. >> (Automake won't generate that option specially for >> gnu-win32, will it? > >Nope. Nor should it. I hate to mention this but since cygwin used to be called "gnu-win32" aren't we going to end up confusing things by adding this to scripts? Also, I believe that the FSF actually asked us to call it something besides gnu-win32 specifically because RMS didn't like the name 'win32' (which is another separate problem). Before adding a name like this to libtool, or autoconf, or whatever, it might be a good idea to get his ruling on this. cgf
Re: Libtool warning message
On Sat, Sep 16, 2000 at 03:55:21PM -0500, Bob Friesenhahn wrote: > Using CVS Automake, Autoconf, and multi-lingual libtool I see the > following message printed from configure: > > checking whether a program can dlopen itself... cat: cannot open conftest.cc > no > > Under Solaris 2.6. > > I believe that the main-branch libtool prints the same message. This looks like a problem in AC_TRY_RUN from cvs autoconf to me. Are you using the CXX tag? If so my guess is that AC_TRY_RUN gets confused about the extension to use for the test file it wants to compile... To be sure, could you try it again with autoconf-2.13 and see whether it goes away, please? Cheers, Gary. -- ___ _ ___ __ _ mailto: [EMAIL PROTECTED] / __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ [EMAIL PROTECTED] | (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \ \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/ home page: /___/ /___/ gpg public key: http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc
Libtool warning message
Using CVS Automake, Autoconf, and multi-lingual libtool I see the following message printed from configure: checking whether a program can dlopen itself... cat: cannot open conftest.cc no Under Solaris 2.6. I believe that the main-branch libtool prints the same message. Bob == Bob Friesenhahn [EMAIL PROTECTED] http://www.simplesystems.org/users/bfriesen
Re: Resolved: multi-language-branch: --tag=CXX not specified
On Sep 16, 2000, Robert Boehne <[EMAIL PROTECTED]> wrote:
> I'm no M4 guru, but it looks right to me. Any ideas?
It might be related with the behavioral differences of AC_REQUIRE
between autoconf 2.13 and CVS autoconf. It works for me, with
autoconf 2.13, but AC_REQUIRE is known to be broken in certain corner
cases in it.
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicampoliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist*Please* write to mailing lists, not to me
Resolved: multi-language-branch: --tag=CXX not specified
Actually I was calling AC_LIBTOOL_CXX from configure.in, the documentation seems to suggest that I should: ... To enable C++ support in libtool, use the `AC_LIBTOOL_CXX' macro in your `configure.in' file. I commented out that call, but it didn't help. What did fix the problem was to put AC_PROG_CXX *before* the call to AC_PROG_LIBTOOL. According to this comment in libtool.m4 it should not matter: dnl If AC_PROG_CXX has already been expanded, run AC_LIBTOOL_CXX dnl immediately, otherwise, hook it in at the end of AC_PROG_CXX. But it will only work if PROG_CXX is called first. From reading the config.log before and after, it is apparent that the C++ configuration is not done unless AC_PROG_LIBTOOL is called after. Alexandre: you wondered what version I'm using, it is up to date with the repository (and was never more than a day from an update). boreas::/boreas/libtool (128)% cvs status libtool.m4 === File: libtool.m4Status: Up-to-date Working revision:1.71.2.33 Repository revision: 1.71.2.33 /home/cvs/libtool/libtool.m4,v Sticky Tag: multi-language-branch (branch: 1.71.2) Sticky Date: (none) Sticky Options: (none) I'm using GNU m4 version 1.4, and CVS versions of automake and autoconf. Could it be that GNU m4 isn't hooking the macro in properly here?: AC_DEFUN(AC_PROG_LIBTOOL,[AC_REQUIRE([_AC_PROG_LIBTOOL]) dnl If AC_PROG_CXX has already been expanded, run AC_LIBTOOL_CXX dnl immediately, otherwise, hook it in at the end of AC_PROG_CXX. AC_PROVIDE_IFELSE([AC_PROG_CXX], [AC_LIBTOOL_CXX], [define([AC_PROG_CXX], defn([AC_PROG_CXX])[AC_LIBTOOL_CXX ])]) I'm no M4 guru, but it looks right to me. Any ideas? PS: I'd like to thank Alexandre and Ossama for helping me out with this one, it certainly would have taken me much longer to find this myself! Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED]
Re: Re[2]: Support pw32 as gnu-win32 target
I would Cc: the cygwin list, but it always bounces my messages...
On Fri, Sep 15, 2000 at 01:55:16PM +0300, Paul Sokolovsky wrote:
> Hello Gary,
Hi!
> Unfortunately, there's no online
> archive of libtool-patches (why?), so I can't look there.
Wierd I added it to geocrawler *ages* ago, bt they haven't picked it
up yet. I've just added it *again*. Maybe this time, eh?
Also the fsf is moving the mailing lists to a new machine, and
changing to mailman. If an archive isn't part of this arrangement,
I'll ask to have one made.
> GVV> Agreed in principle, however we need to be careful of 8.3 again =(O| I
> GVV> guess this means special casing DJGPP.
>
> But how that influence DJGPP or other DOS ports of gcc? That
> change applies only to win32 hosts (in fact, only to gnu-win32, I
> intentionally left hyphen-delimited naming for non-gcc's).
That's true. Doh!
> >> Note comented line with s/^lib/cyg/ - that's about my proposal for
> >> using cyg prefix for cygwin dlls.
>
> GVV> I would like a patch that allows an extra libtool option to name the
> GVV> dll part of a win32 shared library as specified by the developer.
>
> But my original patch (hm, below) would allow to save sensibility
> for something more useful. Don't provide excess configurability when
> it's hardly needed.
But it is. Chris Faylor has specifically denounced the cygfoo.dll
convention, but Chuck Wilson (and presumably yourself) would like an
option to use it for your own ports. It is also more general, rather
than adding a bunch more special cases to libtool, porters can add
'-soname cygfoo.dll' to foo_LDFLAGS if they wish.
> (Automake won't generate that option specially for
> gnu-win32, will it?
Nope. Nor should it.
> And when I would like DLL name to differ from
> standard, I can simply rename it after building.) YMMV
Only if you're prepared to rebuild the import library too.
>if test "$ac_cv_prog_gcc" = yes; then
> -library_names_spec='${libname}`echo ${release} | sed -e
>'s/[.]/-/g'`${versuffix}.dll'
> +case "$host_os" in
> +# cygwin*) library_names_spec=`echo ${libname} | sed -e
>'s/^lib/cyg/'`'${release}${versuffix}.so $libname.dll.a' ;;
> + pw32*) library_names_spec='${libname}${release}${versuffix}.so
>$libname.dll.a' ;;
> + *) library_names_spec='${libname}${release}${versuffix}.dll
>$libname.dll.a' ;;
> +esac
>else
> library_names_spec='${libname}`echo ${release} | sed -e
>'s/[.]/-/g'`${versuffix}.dll $libname.lib'
>fi
Looks good to me. Could you regenerate your patch against the current
HEAD release and repost please?
Cheers,
Gary.
--
___ _ ___ __ _ mailto: [EMAIL PROTECTED]
/ __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ [EMAIL PROTECTED]
| (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \
\___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/
home page: /___/ /___/ gpg public key:
http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc
Re: Can't install CVS libtool
On Fri, Sep 15, 2000 at 08:08:31PM +0200, Bernard Dautrevaux wrote: > Hi all, > > I'm trying to install CVS libtool in my environment and, after > several attempts, I have to request some help. Oops, my bad. I hadn't tried a VPATH build since I removed ltconfig. I checked a fix in earlier this evening, maybe it will help. > The problem is that although ltmain.sh is created correctly, the libtool > script is created using the installed version of libtool :-( It sounds like you have an aclocal with the previous version of libtool.m4 or something. Make sure to run the bootstrap script in the source tree after major changes like the ltconfig patch... > I've verified there is no old version of libtool in $srcdir, nor $srcdir/.. > or above and I don't know why configure creates a libtool script using the > installed ltmain.sh instead of the one it just created Nor I =( > Any Idea of what I could do (short of backing up to the installed version) ? Post a report here, and wait for me to fix it =)O| Failing that you could try a build in the source tree and see if that helps. Cheers, Gary. -- ___ _ ___ __ _ mailto: [EMAIL PROTECTED] / __|__ _ _ ___ _| | / / | / /_ _ _ _ __ _| |_ __ _ ___ [EMAIL PROTECTED] | (_ / _` | '_|// / |/ /| |/ / _` | || / _` | ' \/ _` | _ \ \___\__,_|_|\_, /|___(_)___/\__,_|\_,_\__, |_||_\__,_|//_/ home page: /___/ /___/ gpg public key: http://www.oranda.demon.co.uk http://www.oranda.demon.co.uk/key.asc
