bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re[2]: still many problems under OpenSolaris


From: Vadim Zeitlin
Subject: Re[2]: still many problems under OpenSolaris
Date: Thu, 25 Feb 2010 22:09:16 +0100

On Thu, 25 Feb 2010 21:57:59 +0100 Ralf Wildenhues <address@hidden> wrote:

RW> >  However while this took care of the "echo" problem, it didn't change
RW> > anything with the subsequent ones:
RW> > 
RW> > 1. The files are still compiled with just -DPIC instead of -pic (I guess
RW> >    -DPIC could be left in as well but this is not what counts the most)
RW> 
RW> Yeah, the Libtool macros are fairly dumb in that they only detect Sun
RW> C++ when it's called CC I think.

 Oh. And I thought I'd actually make its life simpler if I called them
sun{cc,CC} as it would definitely know that I'm using Sun compilers then :-/

RW> Is the C compiler pic flag ok though?

 I think so but I didn't test it, I don't have any C-only shared libraries.
Its man page (http://docs.sun.com/source/820-4180/man1/cc.1.html) doesn't
mention -pic flag but it does accept it in practice. And CC man page (at
http://docs.sun.com/source/820-4180/man1/CC.1.html) documents -K{pic,PIC}
in exactly the same way but also documents -pic and -PIC so I wonder if
they didn't just forget to update cc(1).

RW> I guess we could change the match (around line 3826 in current git) to
RW>    CC* | sunCC*)

 I assume we're speaking about libltdl/m4/libtool.m4 file, right? And just
to be certain: what do I need to re-do after modifying this file?

RW> > 2. And I still don't get librlog.so.1.2.4 under .libs, just broken
RW> >    symlinks. Again, this must be because this library is not created in
RW> >    the first place, only librlog.so.1 is and libtool deletes it before
RW> >    recreating it as a symlink.
RW> 
RW> That's hopefully just a followup failure of the above.  Nope, needs
RW> another
RW>   CC* | sunCC*)
RW> 
RW> around line 6258.

 Yes, looks like it should do it, thanks!

 BTW, it might make sense to recognize it under sunCC name under Linux too.
I see the code (line 3769) to do it by running "CC -V" there but it
shouldn't even needed if it's explicitly called sun{cc,CC} and especially
under Linux it does make sense to use this name IMHO to make it clear that
it's not the usual cc -> gcc link.

RW> BTW, what's the output of these for you?
RW>   sunCC -V
RW>   suncc -V

cc: Sun C 5.10 SunOS_i386 2009/06/03
sunCC: Sun C++ 5.10 SunOS_i386 2009/06/03

respectively. AFAIK it's the latest version, i.e. Sun Studio 12.1.

 Thanks again!
VZ

Attachment: pgpbmeVXIMI6v.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]