This is the mail archive of the
mailing list for the Cygwin project.
Re: libtool-devel and kde2
- From: Charles Wilson <cwilson at ece dot gatech dot edu>
- To: Ralf Habacker <Ralf dot Habacker at freenet dot de>
- Cc: cygwin at cygwin dot com
- Date: Mon, 14 Jan 2002 20:59:12 -0500
- Subject: Re: libtool-devel and kde2
- References: <010301c19d49$58da4ec0$fe6207d5@BRAMSCHE>
1) This discussion should be on-list. I've copied this to the cygwin
2) Ummm...you're not USING libtool-devel. You have deliberately
overriden the auto-version detection, and are using
/usr/autotool/stable/* for both "stable" and "devel" projects. (You set
the environment variable AUTO_DEVEL=/usr/autotool/stable)
Ralf Habacker wrote:
> now I have made some tries with the new libtool devel-20010531-rc5.
Nope, you're using libtool stable 1.4.2
> I have build an app using
> a shared lib, which depends on another lib and the dependency code works well.
> Congratulations for your good work.
> I think I will note this on the kde-cygwin website.
> While working with it, I noticed some problems. This may depend on a libtool and
> autoconf/automake relation, which I don't know currently, but let me tell.
> $ cygcheck -c | grep auto
> autoconf 2.52-5
> autoconf-devel 2.52-4
> autoconf-stable 2.13-4
> automake 1.5a-1
> automake-devel 1.5-5
> automake-stable 1.4p5-5
> 1. configure tries to identify the cygwin environment and this fails in some case depending
> on the initial setting of the CC=cc var.
I've never run into this. It always seems to find gcc for me. However,
libtool doesn't handle overriding "CC" very well -- cf. recent
discussion concerning wrapper scripts and 'gcc -mno-cygiwn'. Leave CC
unset within your environment when using libtool.
> $ ./configure
> creating cache ./config.cache
> checking for Cygwin environment... no
> checking for mingw32 environment... no
> checking how to run the C preprocessor... grep: conftest.out: No such file or directory
> ^^^ this depends on using cc instead of gcc
> cc -E
> checking for gcc... gcc
> checking whether the C compiler (gcc ) works... yes
> checking whether the C compiler (gcc ) is a cross-compiler... no
> checking whether we are using GNU C... yes
> The only way to solve this problem seems to be exporting CC=gcc before configuring. Any ideas
> 2. I have problems configuring language specific support with libtool.Unfortunally the kde2
> project is configured with the "Multiple Language Branch"-libtool which creates language
> specific ltcf-c.sh and ltcf-cxx.sh files.
I'm confused. Are you relibtoolizing the project, or just running
configure; make? If you aren't relibtoolizing, then you're not using
the system libtool stuff AT ALL. You're merely using the scripts that
the upstream maintainer copied into the package before you got ahold of it.
If you are relibtoolizing, then it shouldn't matter what version of
libtool the upstream maintainer used -- you're replacing all of that.
Finally, you are NOT using the devel version. You are using 1.4.2 --
pre-MultipleLanguageBranch. The *actual* devel version is based on the
20010531 CVS, which was just after the MLB was merged back to the trunk.
Therefore, the *actual* devel version should support MLB (although I
have not tested it -- and neither have you).
> So using the AC_PROG_CXX in configure.in needs ltconfig for creating a valid configure, which
> seems not be supported by your libtool.
No, it doesn't. As of libtool-1.4 (released April 2001), ltconfig is
not used. http://mail.gnu.org/pipermail/libtool/2001-April/004780.html
So, if it's wanting ltconfig, then it was libtoolized with something
pre-1.4. I can only guess that your packages were libtoolized with a
non-standard libtool taken from the MultiLanguage branch, prior to the
MLB merge (may 2001) AND prior to the ltconfig elimination (Sept 2000).
There seem to be a HOST of contradictions in your post...
> The kdelibs distribution contains such a file in the
> admin dir, but because the relating ltcf-cxx.sh files does not know anything about the cygwin
> patch, the cxx configuration does not created proper dll's. In other words, libtool tries to
> start impgen and so one.
Yes, because apparently your package was libtoolized LONG before any of
those changes made it in.
> On http://fink.sourceforge.net/doc/porting/libtool.php I found some hints relating to this
> topic and there is described, that libtool 1.4 does not support ltconfig.
It's not that it doesn't support it -- it is not needed. All of its
functionality has been moved into libtool.m4:
Gotta go -- don't have time now to respond to the rest of the post...
> With a test project I'm using the following workaround in configure.in.
> to avoid some problems, but this is no solution for the kde2 port. So my question is, how do
> I create valid cxx configurations ?
> 3. libtoolizing with --ltdl - problems to find the aux-dir (may be an autoconf problem)
> I have made a test project with a libltdl subdir and an admin dir, which contains
> administration file as used by kde. The problem is, that configuring the libltdl dir the
> aux-dir was not found.
> Additional I have to use the following lines to create a basic configuration for configuring
> an installable
> libltdl. Instead I expected - as I have read in the doc - the line "AC_LIBLTDL_INSTALLABLE"
> should be enough.
> This causes the kde config to create a convencience not an installable libltdl.
> The following commands are used to create the project, which is appended:
> libtoolize -c -f --ltdl
> cp /usr/autotool/devel/share/aclocal/libtool.m4 acinclude.m4
> automake -a -c --gnu -v
> $ configure
> creating Makefile
> configuring in libltdl
> running /bin/sh ./configure --enable-ltdl-install --cache-file=.././config.cache --srcdir=.
> loading cache .././config.cache
> checking for Cygwin environment... (cached) yes
> checking for mingw32 environment... (cached) no
> checking how to run the C preprocessor... (cached) gcc -E
> configure: error: can not find install-sh or install.sh in . ./.. ./../..
> configure: error: ./configure failed for libltdl
> Thanks for any hints.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html