Re: Call for help: Solaris C++ and Sun CC
In regard to: Re: Call for help: Solaris C++ and Sun CC, Ralf Wildenhues...: While I agree in principle that it would be nice for libtool to help people avoid shooting themselves in the foot, I think in this case it's more important to document the danger than it is to completely mitigate it. I say this primarily because there might be quite a lot of work to actually get libtool to protect the user. A comment in the docs and likely also in the Solaris C++ section of the code would be good enough, I think, unless someone comes up with an easy way to guard against the issue. How about this? [patch elided] I think it's commit-worthy. It certainly helps outline the issue, and points to a source for more information for the people it impacts. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Call for help: Solaris C++ and Sun CC
Hi Albert, Tim, * Albert Chin wrote on Tue, Aug 23, 2005 at 05:07:24AM CEST: On Sun, Aug 21, 2005 at 03:46:13PM +0200, Ralf Wildenhues wrote: We have this compiler on a Solaris 2.6 system and none of /opt/SUNWSpro/lib/libCstd.so, /opt/SUNWSpro/lib/v8plus/libCstd.so, and /opt/SUNWSpro/lib/v9/libCstd.so exist. There is no libCstd.so anywhere in /opt/SUNWspro/lib. OK, good. The system I can test on has just updated to 5.6, too, so that issue is gone.. :) Unfortunately, we don't have CC v5.4 to test against. However, everything about 5.5 works with the patch. I say we gamble and ignore everything below CC v5.4 for this patch. OK. * Tim Mooney wrote on Fri, Aug 26, 2005 at 11:30:58PM CEST: If I'm following that thread correctly, the original problem (needing -lCstd -lCrun -lc for C++) is fixed with Peter's patch and your subsequent fixups. The new issue is that at least Cstd and probably Crun will be linked statically if the admin hasn't added the symlinks in the appropriate place. ACK, at least this is my understanding of the issue. While I agree in principle that it would be nice for libtool to help people avoid shooting themselves in the foot, I think in this case it's more important to document the danger than it is to completely mitigate it. I say this primarily because there might be quite a lot of work to actually get libtool to protect the user. A comment in the docs and likely also in the Solaris C++ section of the code would be good enough, I think, unless someone comes up with an easy way to guard against the issue. How about this? Cheers, Ralf * README, libtool.m4 [ solaris CC ]: Document issue with C++ standard libraries. Index: README === RCS file: /cvsroot/libtool/libtool/README,v retrieving revision 1.17.2.3 diff -u -r1.17.2.3 README --- README 25 Apr 2005 18:13:26 - 1.17.2.3 +++ README 28 Aug 2005 20:56:54 - @@ -122,3 +122,8 @@ 9) Note that newer Sun Studio Fortran compilers might need Autoconf macros not yet present in 2.59 but only in CVS Autoconf. + +10) Note that Sun C++ compiler versions before 5.6 may need some special +setup to link properly against shared versions of the C++ standard libraries. +See http://lists.gnu.org/archive/html/libtool/2005-08/msg00088.html for +more information. Index: libtool.m4 === RCS file: /cvsroot/libtool/libtool/Attic/libtool.m4,v retrieving revision 1.314.2.101 diff -u -r1.314.2.101 libtool.m4 --- libtool.m4 18 Aug 2005 06:56:19 - 1.314.2.101 +++ libtool.m4 28 Aug 2005 20:56:57 - @@ -3749,6 +3749,9 @@ solaris*) case $cc_basename in CC*) +# Adding this requires a known-good setup of shared libraries for +# Sun compiler versions before 5.6, else PIC objects from an old +# archive will be linked into the output, leading to subtle bugs. _LT_AC_TAGVAR(postdeps,$1)='-lCstd -lCrun' ;; esac ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Call for help: Solaris C++ and Sun CC
In regard to: Re: Call for help: Solaris C++ and Sun CC, Ralf Wildenhues...: These two threads contain the patches recently applied to fix the failure with undefined symbols on Solaris with CC (Sun C++ compiler): http://lists.gnu.org/archive/html/libtool-patches/2005-07/msg00088.html http://lists.gnu.org/archive/html/libtool-patches/2005-08/msg00043.html I've never (manually) created these links or the links for libiostream. The system I tested on does not have above unversioned symlinks, and so links against a libCstd.a with PIC objects. Obviously, the libbaz.so created by the 'tagdemo-shared tagdemo-make' tests then has half of libCstd contained in it. Having this huge lib is both uncomfortable and dangerous: when you start linking against several C++ libraries, you can end up with all sorts of very subtle problems. Then I found this documentation. Now I'm unsure whether we should guard against this issue (I'd like to), but more importantly: I don't know how we _can_ guard against it easily. If I'm following that thread correctly, the original problem (needing -lCstd -lCrun -lc for C++) is fixed with Peter's patch and your subsequent fixups. The new issue is that at least Cstd and probably Crun will be linked statically if the admin hasn't added the symlinks in the appropriate place. While I agree in principle that it would be nice for libtool to help people avoid shooting themselves in the foot, I think in this case it's more important to document the danger than it is to completely mitigate it. I say this primarily because there might be quite a lot of work to actually get libtool to protect the user. A comment in the docs and likely also in the Solaris C++ section of the code would be good enough, I think, unless someone comes up with an easy way to guard against the issue. I suppose the test could be special-cased for Solaris, and ldd or some other tool used after linking to verify that a library we're expecting would show up on the list of NEEDED shared libraries, but that seems like a lot of work. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Call for help: Solaris C++ and Sun CC
Hi Tim, * Tim Mooney wrote on Tue, Aug 23, 2005 at 05:25:29PM CEST: In regard to: Re: Call for help: Solaris C++ and Sun CC, Albert Chin said...: On Sun, Aug 21, 2005 at 03:46:13PM +0200, Ralf Wildenhues wrote: So I looked around. I've found this documentation http://docs-pdf.sun.com/806-7982/806-7982.pdf (page 21): | The Sun WorkShop 6 update 2 C++ compiler (5.3) includes a shared | version of the libCstd library. | To use the shared version of libCstd, do the following: | 1. As superuser, manually create the following symbolic links. | | example% ln -s /usr/lib/libCstd.so.1 \ | /opt/SUNWSpro/lib/libCstd.so | example% ln -s /usr/lib/libCstd.so.1 \ | /opt/SUNWSpro/lib/v8plus/libCstd.so | example% ln -s /usr/lib/sparcv9/libCstd.so.1 \ | /opt/SUNWSpro/lib/v9/libCstd.so We have this compiler on a Solaris 2.6 system and none of /opt/SUNWSpro/lib/libCstd.so, /opt/SUNWSpro/lib/v8plus/libCstd.so, and /opt/SUNWSpro/lib/v9/libCstd.so exist. There is no libCstd.so anywhere in /opt/SUNWspro/lib. I missed earlier parts of this thread, so I'm not sure what's being discussed. We do have the Workshop 6u2 environment, including the C++ compiler. These two threads contain the patches recently applied to fix the failure with undefined symbols on Solaris with CC (Sun C++ compiler): http://lists.gnu.org/archive/html/libtool-patches/2005-07/msg00088.html http://lists.gnu.org/archive/html/libtool-patches/2005-08/msg00043.html I've never (manually) created these links or the links for libiostream. The system I tested on does not have above unversioned symlinks, and so links against a libCstd.a with PIC objects. Obviously, the libbaz.so created by the 'tagdemo-shared tagdemo-make' tests then has half of libCstd contained in it. Having this huge lib is both uncomfortable and dangerous: when you start linking against several C++ libraries, you can end up with all sorts of very subtle problems. Then I found this documentation. Now I'm unsure whether we should guard against this issue (I'd like to), but more importantly: I don't know how we _can_ guard against it easily. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Call for help: Solaris C++ and Sun CC
In regard to: Re: Call for help: Solaris C++ and Sun CC, Albert Chin said...: On Sun, Aug 21, 2005 at 03:46:13PM +0200, Ralf Wildenhues wrote: So I looked around. I've found this documentation http://docs-pdf.sun.com/806-7982/806-7982.pdf (page 21): | The Sun WorkShop 6 update 2 C++ compiler (5.3) includes a shared | version of the libCstd library. | To use the shared version of libCstd, do the following: | 1. As superuser, manually create the following symbolic links. | | example% ln -s /usr/lib/libCstd.so.1 \ | /opt/SUNWSpro/lib/libCstd.so | example% ln -s /usr/lib/libCstd.so.1 \ | /opt/SUNWSpro/lib/v8plus/libCstd.so | example% ln -s /usr/lib/sparcv9/libCstd.so.1 \ | /opt/SUNWSpro/lib/v9/libCstd.so We have this compiler on a Solaris 2.6 system and none of /opt/SUNWSpro/lib/libCstd.so, /opt/SUNWSpro/lib/v8plus/libCstd.so, and /opt/SUNWSpro/lib/v9/libCstd.so exist. There is no libCstd.so anywhere in /opt/SUNWspro/lib. I missed earlier parts of this thread, so I'm not sure what's being discussed. We do have the Workshop 6u2 environment, including the C++ compiler. I've never (manually) created these links or the links for libiostream. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Call for help: Solaris C++ and Sun CC
On Sun, Aug 21, 2005 at 03:46:13PM +0200, Ralf Wildenhues wrote: So I looked around. I've found this documentation http://docs-pdf.sun.com/806-7982/806-7982.pdf (page 21): | The Sun WorkShop 6 update 2 C++ compiler (5.3) includes a shared | version of the libCstd library. | To use the shared version of libCstd, do the following: | 1. As superuser, manually create the following symbolic links. | | example% ln -s /usr/lib/libCstd.so.1 \ | /opt/SUNWSpro/lib/libCstd.so | example% ln -s /usr/lib/libCstd.so.1 \ | /opt/SUNWSpro/lib/v8plus/libCstd.so | example% ln -s /usr/lib/sparcv9/libCstd.so.1 \ | /opt/SUNWSpro/lib/v9/libCstd.so We have this compiler on a Solaris 2.6 system and none of /opt/SUNWSpro/lib/libCstd.so, /opt/SUNWSpro/lib/v8plus/libCstd.so, and /opt/SUNWSpro/lib/v9/libCstd.so exist. There is no libCstd.so anywhere in /opt/SUNWspro/lib. Other bits of useful info: http://forum.sun.com/thread.jspa?threadID=25908 I'd like any feedback about possible solutions, general ideas about the issue, or just how *your* Sun CC is set up (with or without these links etc.). Unfortunately, we don't have CC v5.4 to test against. However, everything about 5.5 works with the patch. I say we gamble and ignore everything below CC v5.4 for this patch. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Call for help: Solaris C++ and Sun CC
I need some feedback for a Solaris C++ issue (this is the only issue holding back the 1.5.20 release): We fixed the failure of libtool --mode=link --tag=CXX CC -no-undefined.. with patches from this thread: http://lists.gnu.org/archive/html/libtool-patches/2005-07/msg00088.html http://lists.gnu.org/archive/html/libtool-patches/2005-08/msg00043.html Now, the addition of `-lCstd -Crun' to the link line will usually cause libCstd.so.X and libCrun.so.Y to be added to the DT_NEEDED ELF flag. However, I have encountered a Solaris Workshop 6 update 1 installation which lacks libCstd.so but not libCstd.so.1. Thus, the link will take objects from a static version of libCstd with PIC objects (if I'm not mistaken), and the created C++ library will contain definitions for STL symbols. This is obviously very undesirable, and may lead to huge libraries and subtle trouble with static state variables only noticed much later and after much pain. So I looked around. I've found this documentation http://docs-pdf.sun.com/806-7982/806-7982.pdf (page 21): | The Sun WorkShop 6 update 2 C++ compiler (5.3) includes a shared | version of the libCstd library. | To use the shared version of libCstd, do the following: | 1. As superuser, manually create the following symbolic links. | | example% ln -s /usr/lib/libCstd.so.1 \ | /opt/SUNWSpro/lib/libCstd.so | example% ln -s /usr/lib/libCstd.so.1 \ | /opt/SUNWSpro/lib/v8plus/libCstd.so | example% ln -s /usr/lib/sparcv9/libCstd.so.1 \ | /opt/SUNWSpro/lib/v9/libCstd.so | | For the Intel 32-bit processor architecture, you do not need the last | two links. | | Note -- If your compiler is not installed in the /opt/SUNWSpro | directory, ask your system administrator for the equivalent path on your | system. | | 2. Test the links. | Compile any program with /opt/SUNWSpro/bin/CC, then type the command ldd | a.out. The output shows any dependency on /usr/lib/libCstd.so.1. | | Once these symbolic links are created, libCstd is linked dynamically by | default. | | To link libCstd statically, use the -staticlib-Cstd option. and this (page 52): | Sun WorkShop 6 update 1 Compilers C++ (5.2) includes a shared version of | the libCstd library. | | To use the shared version of libCstd, compile the program in the usual | way, but use a separate link step. In the link step, use the | -library-no%Cstd option, and put the shared library name explicitly on | the command line, as shown in this example. | | example% CC -library=no%Cstd *.o \ | -o myprog /opt/SUNWSpro/WS6U1/lib/libCstd.so.1 I don't see a way to have Libtool work correctly in all cases, and I don't see an easy way to avoid any subtle damage, short of reverting the patches we've applied, if we are to support older versions of the compiler, users without root access, and eventual use of `-staticlib-Cstd'[1]. I'd like any feedback about possible solutions, general ideas about the issue, or just how *your* Sun CC is set up (with or without these links etc.). Thanks, Ralf [1] My best bet would be: ignore version 5.1, assume people that want shared libCstd have set the link, and use the method described for 5.2, namely: test compile, look at `ldd' output. But that possibly sucks for cross-compilation, and requires libtool to use yet another tool. ___ http://lists.gnu.org/mailman/listinfo/libtool
