Re: Problems checking out branch-1-5
Albert Chin [EMAIL PROTECTED] writes: I have CVS 1.11.5: $ cvs -d:pserver:[EMAIL PROTECTED]:/var/cvs login $ cvs -d:pserver:[EMAIL PROTECTED]:/var/cvs co -rbranch-1-5 libtool cvs [server aborted]: received abort signal It also fails for me, but it seems to work fine from subversions.gnu.org. ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Sun C++ shared library creation failing
On Solaris 9/SPARC with: $ CC -v CC: Forte Developer 7 C++ 5.4 Patch 111715-06 2003/03/29 ... PASS: tagdemo-conf.test FAIL: tagdemo-make.test SKIP: tagdemo-exec.test PASS: tagdemo-shared.test FAIL: tagdemo-make.test SKIP: tagdemo-exec.test ... Here's a copy of the error: $ sh tagdemo-make.test ... CC -G -zdefs -nolib -hlibbaz.so.0 -o .libs/libbaz.so.0.0.0 .libs/baz.o -Qoption ld -z -Qoption ld allextract ./.libs/libfoo.a -Qoption ld -z -Qoption ld defaultextract -lm Undefined first referenced symbol in file std::basic_ostreamchar,std::char_traitschar std::operator(std::basic_ostreamchar,std::char_traitschar ,const char*) ./.libs/libfoo.a(foo.o) ... We create a C++ shared library with -nolib which doesn't link in -lCstd, hence the error above. How do we fix? If -nolib isn't used CC adds the following libraries by default: -lCstd -lCrun -lm -lw -lcx -lc Is it really wise to use -nolib? -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Sun C++ shared library creation failing
On Sun, Jun 01, 2003 at 03:47:42PM -0500, Albert Chin wrote: On Solaris 9/SPARC with: $ CC -v CC: Forte Developer 7 C++ 5.4 Patch 111715-06 2003/03/29 ... PASS: tagdemo-conf.test FAIL: tagdemo-make.test SKIP: tagdemo-exec.test PASS: tagdemo-shared.test FAIL: tagdemo-make.test SKIP: tagdemo-exec.test ... Here's a copy of the error: $ sh tagdemo-make.test ... CC -G -zdefs -nolib -hlibbaz.so.0 -o .libs/libbaz.so.0.0.0 .libs/baz.o -Qoption ld -z -Qoption ld allextract ./.libs/libfoo.a -Qoption ld -z -Qoption ld defaultextract -lm Undefined first referenced symbol in file std::basic_ostreamchar,std::char_traitschar std::operator(std::basic_ostreamchar,std::char_traitschar ,const char*) ./.libs/libfoo.a(foo.o) ... We create a C++ shared library with -nolib which doesn't link in -lCstd, hence the error above. How do we fix? If -nolib isn't used CC adds the following libraries by default: -lCstd -lCrun -lm -lw -lcx -lc Is it really wise to use -nolib? Ok, I've dug some more. If we want -zdefs and -nolib, we must add -lCstd (Sun CC 6.0, 7). From libtool.m4: # There doesn't appear to be a way to prevent this compiler from # explicitly linking system object files so we need to strip them # from the output so that they don't get included in the library # dependencies. output_verbose_link_cmd='templist=`$CC -G $CFLAGS -v conftest.$objext 21 | grep \-[[LR]]`; list=; for z in $templist; do case $z in conftest.$objext) list=$list $z;; *.$objext);; *) list=$list $z;;esac; done; echo $list' I'm not seeing this though. CC -G with Sun CC 5.0, 6.0, and 7 don't add any libraries automatically. GCC seems to add -lstdc++ regardless so postdeps gets the -lstdc++ and gets the above test right. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Libtool 1.5 on MacOS X
Because of the way things are set up, adding fsf gcc support is essentially adding a completely different compiler. Depending on my available free time, I may decide to revisit this issue, do you really think it is required? With stock GCC 3.3, most if not all of the Apple-like command line options are processed just as they are on the compiler distributed by Apple. Take a look at the sources and you'll see there are hooks for this. For libtool 1.5, treating stock GCC 3.3 like Apple's GCC works for me to generate dynamic libraries and executables. I just did have a quick peek at the sources, looks like you are indeed correct. I will submit a patch to the list tomorrow. To excuse myself here, almost none of these flags were passed through by the gcc-3.2 fsf gcc which was available when I first looked at this issue. Firstly: Fixing the libtool.m4 macros allowed our project to build on MacOS X using an FSF gcc3.3 compiler. Secondly: I would like to second Marcus' comments that the differences between an Apple compiler and an FSF compiler built on MacOS X are very small. The big difference is the compiler file layout. See the link below for a complete listing of Apple compiler options which highlights the ones not supported on the FSF version. http://developer.apple.com/techpubs/macosx/DeveloperTools/gcc3/gcc/Option-Summary.html#Option%20Summary They involve Apple specific issues such as kext support, Apple ld/dyld support, Pascal strings, pre-compiled headers, Altivec and a couple of Apple legacy compatability things. All of these seem to me to be unlikely to be an issue for cross platform code that wants to use libtool or the FSF compiler. I think the FSF compiler is supposed to support Altivec real soon now. As far as I can see, there is only one issue which prevents our project building with an Apple compiler. This is that the Apple compilers crash trying to compile a main() function with the -fgnu-runtime flag. Bill Northcott ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
RE: A portable way to link in all objects
On Wed, 28 May 2003, Howard Chu wrote: Ronald Landheer-Cieslak wrote: I am looking for a way to portably tell libtool to link in all objects of a given static library. [snip] Link all of the static archive members into a single object file. This works on all platforms: (mkdir foo; cd foo; ar x ../libx1.a; ld -r -o ../libxx.o *.o) rm -rf foo; ar r libxx.a libxx.o You don't need libtool to accomplish this. This is not the kind of answer I was looking for: I am already using libtool for the package and I don't want to change that. What I want is a way to not-manually build a static library that will be completely linked into a not-manually built executable. I.e. I want to be able to tell Libtool to do what you're proposing to do by hand. Theonly way I can see that happening is by adding a line to libmylib.la, telling libtool to link the complete static library into the executable. I.e. I don't want to have to tell people how to link with my libraries *in detail*: I want to be able to just say use Libtool to link to this library and make it transparent to the end user of the library whether he's linking with a static or a shared version of it. As I believe that is more or less the goal of Libtool as well (to make the developer worry about other things than how to run the compiler/linker on the libraries) I think this feature (if missing and not overlooked on my part) might interest the people behind Libtool.. My only real problem is that I don't have, and can't get, a copyright waiver. rlc ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
