Re: GMP: IBM mainframe build results
* Tim Van Holder wrote on Fri, Jul 13, 2007 at 04:11:43PM CEST: > Ralf Wildenhues wrote: > >> - [LIBTOOL] by default, the compilers require that files come last on > >> the command line, and many versions of libtool (including the one > >> included with GMP) break this rule when configure has determined -c > >> and -o can both be used (it puts the -o last). To work around this, > >> the envvar _CC/C89/CXX_CCMODE needs to be set to 1. > > > > This we can probably fix. Please post > > ./libtool --config > > Attached as libtool.config. Thanks. I needed to think a bit more about this. If I understand you correctly, then the failure occurs at 'make' time rather than at 'configure' time, right? And it's the linking steps of *programs* that fail rather than compilation (with -c; automake always puts the source file last when compiling), and neither the generation of libraries, because you only generate static ones with ar. Right? Could you post an actual of this failing command, including commands that generated it, if any? > > also the depmode configure has settled on. Thanks. > > No depmode - the compiler has no -M option or equivalent, which is a > serious PITA when trying to fix portability issues (change a header and > you're forced to make clean to make sure you catch all clients of that > header - and when a compile takes hours, that's not fun). Well you can enable trying the slow dependency extractors with ./configure --enable-dependency-tracking then also things like makedepend or "parsing" preprocessor output (by the depcomp script) will be tried. > >> - I didn't build the C++ wrappers, but because they use the .cc > >> extension, the _CXX_CXXSUFFIX envvar would need to be set to "cc" to > >> succeed (by default, the compiler only accepts foo.C as a C++ source). > > > > Yuck. MSVC needs .cpp, so to avoid having to set this, Autoconf would > > need a further test for $ac_ext in the C++ case. Also, it's not > > feasible to expect that user code change their file names on the fly, so > > I assume that since your compiler can be taught (by _CXX_CXXSUFFIX) it > > is better to stick with '.cpp'. :-/ > > As far as I can tell, autoconf makes no attempt to detect the extension > at all - what's worse, the extension it tries seems to be > version-dependent; for gmp and libxml2 it uses .cc for its conftest > files (so I had set $_CXX_CXXSUFFIX in my .profile to make the problem > go away), but I'm trying to configure libiconv now, where autoconf uses > .cpp. I suppose this is really an autoconf failing - it should perhaps > try cc, cpp and C and use whichever the compiler accepts. Well, yes, that was sort of what I was trying to say: Autoconf changed from '.cc' to '.cpp' exactly because nobody could report a compiler that failed with '.cpp', but there was a report that MSVC would mess up with '.cc'. It's your report now that made me (at least) aware of a compiler that needed '.cc'. The fact that you have a compiler that understands only '.cc' should be reported to bug-autoconf. (I assume the above is long-winded for violent agreement. ;-) > >> - [LIBTOOL] During installation, the "libraries have been installed in" > >> message is shown, but the shell's print builtin (used in $echo) shows > >> an error for the line of dashes: > >> print: ./libtool 6200: FSUM6241 Unknown option "--" > >> print: ./libtool 6200: Usage: print [-nprRsu[n]] [arg ...] > >> Preceding the string with -- makes this go away ($echo -- "--..."). OK, this should be fixed in a newer Libtool release. > >> - [LIBTOOL] MAJOR: The system 'ar' does not store paths, only basenames, > >> and during the (piecewise) link of libgmp.la, multiple files with the > >> same basename are given to ar, resulting in messages like: [...] > > This has most definitely seen bugfixing since 1.5.6. We'd be interested > > in issues occurring with 1.5.24 or CVS HEAD here. > > OK - but since I don't have autotools set up, I can't easily update the > libtool in use by GMP (and since it would take >10 hours for me to get a > result if I did, I'm not that inclined to try either). If a future > version of GMP uses such a newer libtool, and I have cause to build that > on OpenMVS, I'll let you know what I get though. One thing you can do that's more time-efficient is to download libtool-1.5.24, build it, go back to your gmp build tree where everything is already built that's needed for libgmp.la, enter the directory where libgmp.la is created and env LIBTOOL=/path/to/libtool-1.5.24-build/libtool make -e libgmp.la (Bourne shell notation) which should work. Hope that helps. Cheers, and thanks, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
How to create shared library(dll) without lib prefix ?
Let a project use libtool to make libraries. In case of mingw build (cross-compilation) in many cases is good dll to be without lib prefix. In these cases cross-compilation can create dlls with same names as native build and those dlls can be used instead native build. The name of import library can left libNAME.dll.a. When building shared libraries on unix usually Makefile.am contain lib_LTLIBRARIES = lib.la and result is lib.so... It is similar to case for pcre.la (topic "dll names on windows") but with lib-prefix for la-file. How to do this? Notes: - libtool macro AC_LIBTOOL_SYS_DYNAMIC_LINKER don't preserve "libname_spec" set by CONFIG_SITE so that I cannot use "libname_spec="\$name"" in CONFIG_SITE file; - same for "soname_spec"; - LDFLAGS -module is only to inform automake that we use "nonstandard" name, i.e without lib prefix. This is not my case since for other systems lib prefix is fine. Also note that with argument "-module" file is installed in libdir (!) and without in bindir; - to use def-file with content "LIBRARY NAME.dll" and to pass to linker by example with -export-symbols. In this case import library "libNAME.dll.a" is created for "NAME.dll" but dll-name is "libNAME.dll". We can rename dll (to remove lib prefix) and in file "libNAME.la" to remove lib-prefix in dlname. In this case libtool will install "NAME.dll", i.e. without lib prefix, but create in libdir la-file with dlname='../bin/libNAME.dll' so that we should edit again. More info: Command: $i386-mingw32msvc-gcc -shared ... -o .libs/.dll ... -Xlinker --out-implib -Xlinker .libs/lib.dll.a" create dll without lib prefix and put .dll in import library. Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
libtool 1.5.22 passes ld options to gcc on ia64-hp-hpux11.23?
With libtool 1.5.22 and gcc 4.0.4/4.2.0 on ia64-hp-hpux11.23, I see
libtool passing "+b /some/path" directly to "gcc -shared" rather than
escaping it via "-Wl,":
hpbox# sh ../libtool --mode=link gcc -rpath
/usr/local/lib -version-info 16:0:1 -o libnetsnmpagent.la *.lo
../snmplib/libnetsnmp.la
gcc -shared -Wl,+h -Wl,libnetsnmpagent.so.16
-Wl,+nodefaultrpath -o .libs/libnetsnmpagent.so.16.0
.libs/agent_handler.o .libs/agent_index.o .libs/agent_read_config.o
.libs/agent_registry.o .libs/agent_trap.o .libs/kernel.o
.libs/snmp_agent.o .libs/snmp_perl.o .libs/snmp_vars.o +b
/tmp/test/snmplib/.libs ../snmplib/.libs/libnetsnmp.so -lc
gcc: +b: No such file or directory
configure-generated libtool contains:
CC="gcc"
LD="/usr/ccs/bin/ld"
hardcode_libdir_flag_spec="\${wl}+b \${wl}\$libdir"
hardcode_libdir_flag_spec_ld="+b \$libdir"
archive_cmds="\$CC -shared \${wl}+h \${wl}\$soname \${wl}+nodefaultrpath
-o \$lib \$libobjs \$deplibs \$compiler_flags"
Changing hardcode_libdir_flag_spec_ld to match hardcode_libdir_flag_spec
works around the issue.
Am I correct to assume that this is fixed in 1.5.24 due to the following
change?
2006-06-12 Ralf Wildenhues <[EMAIL PROTECTED]>
* ltmain.in (link mode): Disregard
`hardcode_libdir_flag_spec_ld' if we're using `$CC' to link.
* libtool.m4 () [ hpux10, hpux11; hppa*64*, ia64* ]
: Removed.
Reported by Roger While <[EMAIL PROTECTED]>.
+Thomas
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.22 passes ld options to gcc on ia64-hp-hpux11.23?
Hello Thomas, * Thomas Anders wrote on Tue, Jul 17, 2007 at 12:08:47AM CEST: > With libtool 1.5.22 and gcc 4.0.4/4.2.0 on ia64-hp-hpux11.23, I see > libtool passing "+b /some/path" directly to "gcc -shared" rather than > escaping it via "-Wl,": [...] > Am I correct to assume that this is fixed in 1.5.24 due to the following > change? I hope so. But if you could try 1.5.24 out and confirm, then that would be even better. ;-) Thanks, Ralf > 2006-06-12 Ralf Wildenhues <[EMAIL PROTECTED]> > * ltmain.in (link mode): Disregard > `hardcode_libdir_flag_spec_ld' if we're using `$CC' to link. > * libtool.m4 () [ hpux10, hpux11; hppa*64*, ia64* ] > : Removed. > Reported by Roger While <[EMAIL PROTECTED]>. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: libtool 1.5.22 passes ld options to gcc on ia64-hp-hpux11.23?
Ralf Wildenhues wrote: > I hope so. But if you could try 1.5.24 out and confirm, then that would > be even better. ;-) The build has just finished successfully. Confirmed. :-) +Thomas ___ http://lists.gnu.org/mailman/listinfo/libtool
Loadable modules with FSF compilers on Darwin MacOS X
There is a problem building loadable modules on Darwin/MacOS X using
libtool and FSF compilers.
A typical build failure looks like this:
/bin/sh ../../../libtool --tag=CXX --mode=link /usr/local/gcc4.0/
bin/g++ -g -O2 -o basefunctions.la -rpath /usr/local/lib/jags/
modules -no-undefined -module -avoid-version basefunctions_la-
Add.lo basefunctions_la-Divide.lo basefunctions_la-Equals.lo
basefunctions_la-Multiply.lo basefunctions_la-Neg.lo
basefunctions_la-Pow.lo basefunctions_la-Subtract.lo
basefunctions_la-module.lo ../../../src/lib/libjags.la -lm
/usr/local/gcc4.0/bin/g++ -o .libs/basefunctions.so -bundle .libs/
basefunctions_la-Add.o .libs/basefunctions_la-Divide.o .libs/
basefunctions_la-Equals.o .libs/basefunctions_la-Multiply.o .libs/
basefunctions_la-Neg.o .libs/basefunctions_la-Pow.o .libs/
basefunctions_la-Subtract.o .libs/basefunctions_la-
module.o ../../../src/lib/.libs/libjags.dylib -lm
i686-apple-darwin8-g++-4.0.3: couldn't run '/usr/local/gcc4.0/bin/
undle-gcc-4.0.3': No such file or directory
There is always some complaint about a missing file or directory
whose name starts with 'undle'.
The immediate cause can be seen in the g++ command above where '-
bundle' is the second option. Unless -bundle is the first option on
the command line, it is interpreted as '-b undle' which causes the
errors.
In the package concerned the cause seems to be around line 220 of the
configured libtool where one finds:
module_cmds="\$CC \$allow_undefined_flag -o \$lib -bundle \$libobjs
\$deplibs\$compiler_flags"
module_expsym_cmds="sed -e \\\"s,#.*,,\\\" -e \\\"s,^[]*,,\\\" -
e \\\"s,^(..*),_&,\\\" < \$export_symbols > \$output_objdir/
\${libname}-symbols.expsym~\$CC \$allow_undefined_flag -o \$lib -
bundle \$libobjs \$deplibs\$compiler_flags~nmedit -s \
$output_objdir/\${libname}-symbols.expsym \${lib}"
Of course it is easy enough to rearrange those lines and get it to
build, but it seems to me like a bug in libtool. Alternatively, it
is a bug in the compiler, although I think it is documented somewhere.
The version here is 1.5.22 on MacOS X 10.4.10 Intel using the gcc
compilers distributed with R-2.4.1.
Using Apple's compilers there does not seem to be the same issue
maybe they require -b to be followed by a space.
I know I am not the only one to hit this problem.
Bill Northcott
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: Loadable modules with FSF compilers on Darwin MacOS X
Forget that last message. The problem I have is definitely in the compiler driver gcc/g++ Apologies Bill On 17/07/2007, at 4:00 PM, Bill Northcott wrote: There is a problem building loadable modules on Darwin/MacOS X using libtool and FSF compilers. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: GMP: IBM mainframe build results
Ralf Wildenhues wrote: > * Tim Van Holder wrote on Fri, Jul 13, 2007 at 04:11:43PM CEST: >> Ralf Wildenhues wrote: - [LIBTOOL] by default, the compilers require that files come last on the command line, and many versions of libtool (including the one included with GMP) break this rule when configure has determined -c and -o can both be used (it puts the -o last). To work around this, the envvar _CC/C89/CXX_CCMODE needs to be set to 1. >>> This we can probably fix. Please post >>> ./libtool --config >> Attached as libtool.config. > > Thanks. I needed to think a bit more about this. If I understand you > correctly, then the failure occurs at 'make' time rather than at > 'configure' time, right? And it's the linking steps of *programs* that > fail rather than compilation (with -c; automake always puts the source > file last when compiling), and neither the generation of libraries, > because you only generate static ones with ar. Right? Both compiles and links are affected. For the linking, automake puts the -o at the end itself, so it is at least partially to blame. Then again, libtool does already move the -o to a place before the list of libraries, so it could just as easily move it before the object file name too. For the compilation, the relevant bit in ltmain.sh is (line 989 in the first ltmain.sh that comes to hand): if test "$pic_mode" != yes; then # Don't build PIC code command="$base_compile $qsrcfile" else command="$base_compile $qsrcfile $pic_flag" fi if test "$compiler_c_o" = yes; then command="$command -o $obj" fi If this is changed to command=$base_compile if test "$pic_mode" = yes; then command="$base_compile $pic_flag" fi if test "$compiler_c_o" = yes; then command="$command -o $obj" fi command="$command $qsrcfile" I believe that it will retain its current functionality while also guaranteeing the source file comes last. Currently, even without -c -o being able to be used together, it would still put -fPIC or whatever at the end -- not an issue for OpenMVS (no PIC flag detected), but it could cause similar invocation troubles on some other host. > Could you post an actual of this failing command, including commands > that generated it, if any? These are from libiconv, not GMP, but that shouldn't matter. Linking: /bin/sh ../libtool --mode=link /bin/c89 iconv_no_i18n.o ../srclib/libicrt.a ../lib/libiconv.la -o iconv_no_i18n mkdir .libs chmod 777 .libs /bin/c89 iconv_no_i18n.o -o iconv_no_i18n ../srclib/libicrt.a ../lib/.libs/libiconv.a FSUM3008 Specify a file with the correct suffix (.c, .i, .s, .o, .x, .p, .I, or .a), or a corresponding data set name, instead of -o. Compiling: /bin/sh ../libtool --mode=compile /bin/c89 -I. -I. -I.. -I./.. -I../include -g -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED -DLIBDIR=\"/usr/local/lib\" -DBUILDING_LIBCHARSET -DBUILDING_DLL -DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\"/usr/local/lib\" -DNO_XMALLOC -Dset_relocation_prefix=libcharset_set_relocation_prefix -Drelocate=libcharset_relocate -DHAVE_CONFIG_H -c ./relocatable.c /bin/c89 -I. -I. -I.. -I./.. -I../include -g -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED -DLIBDIR=\"/usr/local/lib\" -DBUILDING_LIBCHARSET -DBUILDING_DLL -DENABLE_RELOCATABLE=1 -DIN_LIBRARY -DINSTALLDIR=\"/usr/local/lib\" -DNO_XMALLOC -Dset_relocation_prefix=libcharset_set_relocation_prefix -Drelocate=libcharset_relocate -DHAVE_CONFIG_H -c ./relocatable.c -o relocatable.o FSUM3008 Specify a file with the correct suffix (.c, .i, .s, .o, .x, .p, .I, or .a), or a corresponding data set name, instead of -o. >>> also the depmode configure has settled on. Thanks. >> No depmode - the compiler has no -M option or equivalent, which is a >> serious PITA when trying to fix portability issues (change a header and >> you're forced to make clean to make sure you catch all clients of that >> header - and when a compile takes hours, that's not fun). > > Well you can enable trying the slow dependency extractors with >./configure --enable-dependency-tracking > > then also things like makedepend or "parsing" preprocessor output (by > the depcomp script) will be tried. I can try - but things are very slow as they are, and I'm loathe to introduce even more slowdown. Still, it would help for packages where I need to do nontrivial porting work. Thanks. > Autoconf changed from '.cc' to '.cpp' exactly because nobody could > report a compiler that failed with '.cpp', but there was a report that > MSVC would mess up with '.cc'. It's your report now that made me (at > least) aware of a compiler that needed '.cc'. The fact that you have a > compiler that understands only '.cc' should be reported to bug-autoconf. > (I assume the above is long-winded for violent agreement. ;-) It is (and the compiler by default works for neither .cc nor .cpp - it needs .C). I'll file a report with autoconf wh
