Re: libtool uses cc to link a mixed C/C++ project and fails to find operator new
On 6/23/19 2:56 PM, Yuri wrote: On FreeBSD libtool can't find operator new[] because it is in C mode: libtool: link: cc -fno-strict-aliasing -fopenmp -ftree-vectorize -pthread -O2 -pipe -fno-omit-frame-pointer -fstack-protector-strong -fno-strict-aliasing -fno-strict-aliasing -fstack-protector-strong -o RNALfold RNALfold_cmdl.o RNALfold.o ../../src/ViennaRNA/.libs/libRNA_conv.a ./.libs/libhelpers.a -lm -pthread -fopenmp libtool: link: cc -fno-strict-aliasing -fopenmp -ftree-vectorize -pthread -O2 -pipe -fno-omit-frame-pointer -fstack-protector-strong -fno-strict-aliasing -fno-strict-aliasing -fstack-protector-strong -o RNALalifold RNALalifold_cmdl.o RNALalifold.o ../../src/ViennaRNA/.libs/libRNA_conv.a ./.libs/libhelpers.a -lm -pthread -fopenmp ld: error: undefined symbol: operator new[](unsigned long) >>> referenced by svm.cpp >>> svm.o:(Kernel::Kernel(int, svm_node* const*, svm_parameter const&)) in archive ../../src/ViennaRNA/.libs/libRNA_conv.a I added "LT_LANG([C++]) to configure.ac but it didn't help: AC_PROG_LIBTOOL LT_INIT([pic-only, static]) LT_LANG([C++]) AC_SUBST(LIBTOOL_DEPS) How to switch libtool to the C++ mode? Are you using automake? Or just libtool and autoconf? With automake, the info at the end of the following section in the manual might help: https://www.gnu.org/software/automake/manual/automake.html#Libtool-Convenience-Libraries I think the same idea applies to executable files, not just building libraries from a collection of convenience libraries. So (again, with automake) you can trick the system into using C++ for linking by having a C++ source file directly in the list of files to link. That C++ source file doesn't have to contain anything or even exist. Automake just notes that there is a C++ file in the list of files to link and uses the C++ linker. jwe ___ https://lists.gnu.org/mailman/listinfo/libtool
Re: 1,000 year backward compatability of tools
On 19-Feb-2003, Bruce Korb <[EMAIL PROTECTED]> wrote: | Paul Eggert wrote: | > | > Personally I'm becoming more inclined to start using shell functions. | > Perhaps in Autoconf 3. | | If my memory serves, GCC has finally said, "Enough with K&R already!" | but everyone is still saying, "You first." and "No, after you." | It's silliness. The only people squawking are the ones jealously | looking out for someone who maybe might be using the stuff. Sweating | K&R-isms and copying shell text to avoid functions is a waste of | developer time. Even if money isn't paid, there's still a big cost. | It's past time. I agree. It all adds up to a lot of wasted effort trying to support old stuff that only a few people use. Paul Eggert mentioned Ultrix as a system that had a /bin/sh without support for shell functions. That's true, I used to be one of its victims^H^H^H^H^H^H^H users, and I remember it just as if it were yesterday (actually, it has been more than 7 years now, but the wounds are still healing). In any case, even Ultrix had another shell, /bin/sh5, if I remember correctly, that did support shell functions, and it would not have been too difficult for configure to attempt to find it (or bash, if that happened to be installed), and then re-exec itself using the more functional shell. I'm not sure why that was never done. Back when it would have mattered, bash was not even using an autoconf-generated configure script, so there wouldn't have even been a (serious) bootstrapping problem on most other widely used systems of the time. But now? Do we really have to worry about these old systems? If people enjoy the vintage hardware, then is it that bad if they can only use vintage software on it as well? jwe -- www.octave.org| Unfortunately we were hopelessly optimistic in 1954 www.che.wisc.edu/~jwe | about the problems of debugging FORTRAN programs. | -- J. Backus ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
