Re[2]: Support pw32 as gnu-win32 target
Hello Gary,
Gary V. Vaughan [EMAIL PROTECTED] wrote:
GVV On Sun, Sep 10, 2000 at 12:57:46PM +0300, Paul Sokolovsky wrote:
Hello libtool-patches,
GVV Hello =)O|
Here's first chunk of my patches - since some are probably will
require corrections, I decided to split them starting with most
harmless.
GVV Thanks, that is much appreciated. However you attachments have been
GVV truncated, or else you generated the patch with the wrong version.
GVV Almost all of what you mention in the Changelog entry is missing =(O|
Strange, I did diff against CVS head, copy of message returned to
me contains everything I put there. Unfortunately, there's no online
archive of libtool-patches (why?), so I can't look there.
There are support for pw32,
GVV I can see some of this, but it was incomplete. I have applied
GVV something similar, under the assumption that pw32 takes '/' delimited
GVV paths, and has no libc or libm (-lc and -lm are discarded). It is no
GVV coincidence that this is the same mode of operation of libtool under
GVV cygwin =)O|
Thanks! That's what I wanted first of all - shorten size of my
patches.
giving up using hyphens as revision numbers delimiters,
GVV DJGPP (and presumably other DOS ports of gcc) uses 8.3 filenames, so
GVV only a single `.' is allowed. I accept that the current
GVV libfoo-p-q-r.dll already violates the 8.3 limit, but I would like to
GVV support DJGPP better than we do already. I guess this means I need to
GVV install it, and see what breaks. Awaiting your patch =)O|
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). Only time
this may apply is when cross-compiling from djgpp to gun-win32 host.
Well, then:
- If it is done on one of win9x systems, LFN facility is used which
transparently proxies win32 naming to djgpp apps.
- For NT systems, there're separate package to achieve that.
- Only when one does that on bare dos, that will be problem. But I
guess it's fair to suggest in such case to take care that djgpp
convert filenames to representation acceptable by underlying layer.
(And IMHO, this might be done in official djgpp - well, maybe it's
even done already, I'm looking at 2.01 _put_path()).
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. I
GVV think the cleanest way to do this is to add a `-soname FILENAME'
GVV option to the link mode of ltmain.in, which on win32 is use to name
GVV the dll part, but is passed to the linker by default. Maybe we need
GVV to intercept -Xlinker,-soname and -Wl,-soname too? Alexandre, do you
GVV have any suggestions on how to go about this?
GVV Anyway, such a system will allow sensible cygwin developers to use
GVV libtool --mode=link gcc -no-undefined -soname cygfoo.dll
GVV And you to use
GVV libtool --mode=link gcc -no-undefined -soname pwfoo.dll
GVV from the same codebase.
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. (Automake won't generate that option specially for
gnu-win32, will it? And when I would like DLL name to differ from
standard, I can simply rename it after building.) YMMV
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
GVV Cheers,
GVV Gary.
--
Paul Sokolovsky, IT Specialist
http://www.brainbench.com/transcript.jsp?pid=11135
Can't install CVS libtool
Hi all,
I'm trying to install CVS libtool in my environment and, after
several attempts, I have to request some help.
I've get the latest CVS version (as of 2000-09-15) and run bootstrap in the
source directory.
I then move in the build directory (a sub-directory of the source directory)
then configure and make:
canopus{SoftWrks}: ../configure --srcdir=.. --enable-maintainer-mode
--disable-multilib \
--prefix=/global/scripts --exec-prefix=/usr/local --disable-shared
--with-mmalloc \
--build=i386-pc-solaris2.7
canopus{SoftWrks}: make
Making all in .
make[1]: Entering directory
`/global/targets/V3/i386-unknown-solaris2.4/Imported/gnu/libtool/libtool-nat
ive'
CONFIG_FILES=libtoolize CONFIG_HEADERS= ./config.status
creating libtoolize
chmod +x libtoolize
make[1]: Leaving directory
`/global/targets/V3/i386-unknown-solaris2.4/Imported/gnu/libtool/libtool-nat
ive'
Making all in libltdl
make[1]: Entering directory
`/global/targets/V3/i386-unknown-solaris2.4/Imported/gnu/libtool/libtool-nat
ive/libltdl'
cd ../../libltdl /bin/sh
/global/targets/V3/i386-unknown-solaris2.4/Imported/gnu/missing --run
autoheader
autoheader: config.h.in is unchanged
/bin/sh ./libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I../../libltdl -I.
-g -O2 -c -o ltdl.lo ../../libltdl/ltdl.c
libtool: ltconfig version `' does not match ltmain.sh version `1.3.5'
make[1]: Leaving directory
`/global/targets/V3/i386-unknown-solaris2.4/Imported/gnu/libtool/libtool-nat
ive/libltdl'
Fatal configuration error. See the libtool docs for more information.
make[1]: *** [ltdl.lo] Error 1
make: *** [all-recursive] Error 1
canopus{SoftWrks}:
The problem is that although ltmain.sh is created correctly, the libtool
script is created using the installed version of libtool :-(
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
Any Idea of what I could do (short of backing up to the installed version) ?
TIA
Bernard
Bernard Dautrevaux
Microprocess Ingenierie
97 bis, rue de Colombes
92400 COURBEVOIE
FRANCE
Tel:+33 (0) 1 47 68 80 80
Fax:+33 (0) 1 47 88 97 85
e-mail: [EMAIL PROTECTED]
[EMAIL PROTECTED]
Re: multi-language-branch: --tag=CXX not specified
On Sep 14, 2000, Robert Boehne [EMAIL PROTECTED] wrote:
/bin/sh ../../libtool --mode=compile g++ -DHAVE_CONFIG_H -I. -I. -I../..
[snip]
libtool: compile: unable to infer tagged configuration
libtool: compile: specify a tag with `--tag'
libtool.m4, that should be part of aclocal.m4, hooks into AC_PROG_CXX
some code to automatically add a CXX tag to libtool. If you don't use
AC_PROG_CXX or you're using an incompatible libtool.m4, you will get
an error like this.
Also, I read the documentation on how to port libtool, however
it doesn't cover (as far as I could find) porting of C++ support.
It's highly outdated, at this point. Basically, you have to modify
ltcf-cxx.sh. Take a look at it and see if it makes any sense for you
:-)
--
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
Re: multi-language-branch: --tag=CXX not specified
Hi Robert, On Fri, Sep 15, 2000 at 03:37:37PM -0500, Robert Boehne wrote: I can now run "make" from the top level and the library will be built. Perhaps there is some confustion using libtool with CXX and CC for files in the same Makefile? This should be transparent. A couple of months ago I added a feature to libtool that automatically selects which tagged configuration to use, even without the "--tag" argument, to specifically handle the situation you describe above. I'll try to reproduce the problem you're getting but I'm fairly certain that this feature was working a few months ago. -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Re: multi-language-branch: --tag=CXX not specified
Hi Robert, I only noticed the following after I posted my last message: On Fri, Sep 15, 2000 at 03:37:37PM -0500, Robert Boehne wrote: libtool: compile: unable to infer tagged configuration libtool: compile: specify a tag with `--tag' Are you using a C++ compiler different (even if only by name) from the one libtool was configured with? Specifically, is the "CXX" tagged configuration set up to use "c++" or "g++?" The above message implies that the libtool configured compiler and the compiler passed by automake are different. Is this the case? BTW, the above message is coming from the automatic tagged configuration selection code I mentioned in my last message. Thanks, -Ossama -- Ossama Othman [EMAIL PROTECTED] Distributed Object Computing Laboratory, Univ. of California at Irvine 1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Re: multi-language-branch: --tag=CXX not specified
Hi Alexandre,
On Fri, Sep 15, 2000 at 06:58:02PM -0300, Alexandre Oliva wrote:
On Sep 15, 2000, Robert Boehne [EMAIL PROTECTED] wrote:
% ../../libtool --tag=CXX --config | grep '^CC=' | tail -1
CC="cc"
That's the problem. It should be 'g++', in the CXX configuration.
Remove the `tail -1' and make sure you get two lines, one for the
default configuration and one overrider for CXX.
Then go figure why ltconfig got the wrong value when creating the CXX
configuration. Search for `TAG CONFIG: CXX' to see the configuration
variables passed to ltconfig. Also check what version of libtool
you're using.
Robert sent me his generated libtool script. Part of the CXX
configuration is listed below. It appears that ltconfig wasn't
invoked properly. The C++ compiler was not set when configuring the
C++ tagged configuration.
### BEGIN LIBTOOL TAG CONFIG: CXX
# Libtool was configured as follows, on host boreas:
#
# AR="" AR_FLAGS="" LTCC="gcc" CC="" \
# CFLAGS="" CPPFLAGS="" \
# MAGIC="" LD="" LDFLAGS="" LIBS="" \
# LN_S="ln -s" NM="/bin/nm -B" RANLIB="ranlib" STRIP="strip" \
# AS="" DLLTOOL="" OBJDUMP="" \
# objext="" exeext="" reload_flag=" -r" \
# deplibs_check_method="pass_all" \
# file_magic_cmd="\${MAGIC}" \
# make/ltconfig -o libtool --cache-file=/dev/null --with-gcc
--build=powerpc-ibm-aix4.3.3.0 --add-tag=CXX make/ltcf-cxx.sh
powerpc-ibm-aix4.3.3.0
#
BTW, Robert thanks so much for working on the AIX port! I've been
aching to get that port completed but since I don't have access to an
AIX box I've been waiting for someone to come along to help out. :-)
-Ossama
--
Ossama Othman [EMAIL PROTECTED]
Distributed Object Computing Laboratory, Univ. of California at Irvine
1024D/F7A394A8 - 84ED AA0B 1203 99E4 1068 70E6 5EB7 5E71 F7A3 94A8
Re: multi-language-branch: --tag=CXX not specified
On Sep 15, 2000, Ossama Othman [EMAIL PROTECTED] wrote:
Robert sent me his generated libtool script. Part of the CXX
configuration is listed below. It appears that ltconfig wasn't
invoked properly.
Then I'll re-iterate the question of what version of the libtool
scripts and libtool.m4 he's using. Also, what are the libtool-related
macros called in configure.in? Is AC_LIBTOOL_CXX being called
explicitly (it shouldn't), or is it called implicitly by the
AC_PROG_CXX hook?
--
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
