Please see my comments inline. --- On Fri, 5/22/09, David Korn <[email protected]> wrote:
> From: David Korn <[email protected]> > Subject: Re: [uwin-users] a wild guess on 'cc', 'pcc', MSVC, UNIXish OSes > and Windows > To: [email protected], [email protected] > Date: Friday, May 22, 2009, 1:28 PM > cc: [email protected] > Subject: Re: [uwin-users] a wild guess on 'cc', 'pcc', > MSVC, UNIXish OSes and Windows > -------- > > > Hello All, > > > > as I have stated many times, 'pcc.c' is not in the > source tarball - I'm still > > waiting for a confirmation. > I will have to check. If it is not there, it could be > because it > is in the uwin development package. I don't do the > packaging anymore > so I will have find out why. > > > > Now I think I understand the "whole" picture. > > > > 'cc' wrapper, according to my observation, doesn't > work except maybe with > > MSVC - I simply haven't tried it yet with MSVC. > The cc wrapper is only supposed to wrap compilers running > on Windows. > It is not a wrapper for compilers on UNIX. > > > > OTOH, there is native 'cc' under Linux: > > > > ls -ltr `which cc` > > lrwxrwxrwx 1 root root 7 2008-10-08 02:25 /usr/bin/cc > -> gcc-4.2 > > . > > > > And that native 'cc' pretty much works with UWIN under > Linux - quite a lot > > of stuff can be built with it, though not everything, > and the targets at > > least in part fail due to reasons not related to > compiler. > That native cc only supports gcc, not MSVC and when I tried > it it had > a lot of problems. Also, each of the compilers on > windows used different > option specifications. We wanted a compiler interface > that worked > on all systems and could build dlls simply with gcc, msvc, > or any > native compiler. This way our make files do not > depend on the compiler > directly. If you look at the ast package you will see > compiler > independent Makefiles that work with gcc, Sun cc, Hp cc, > IBM cc, MVS cc, > and UWIN supported compilers as well as others. > > > > Since UWIN and its 'cc' doesn't work with non-MSVC > compilers, had UWIN > > 'cc' been built under Linux, it would have screwed up > the rest of the > > build - because it doesn't work. > It used to work with 4 compilers on UWIN. It never > worked or intended > to work on Linux. > > > > So, it looks it's not in the source tarballs for this > reason. > No, this is not the release. The uwin source tarball > contains > windows specific source code. The ast source tarball > is for all > unix and unix-like systems. > > > > Now, if it's the truth, source tarballs should be > organized differently - > > there should be a separate one for UWIN 'cc'. > Why? It only makes sense for compilation > on UWIN. > > > > And this truth should be prominently written on the > UWIN website - too > > much effort has to be spent just to come to this > truth, so why should > > every newcomer spend this effort ? > As far as I am aware, you are the only one to come to this > conclusion. > We have never made any other claim about the UWIN cc > compiler wrapper. > If others have had a similar proble, I would like to hear > from you. When I build all the downloaded tarballs under Linux, 'make' calls 'cc', not 'gcc'. As I showed above, under Linux 'cc' is a symbolic link to 'gcc'. 'cc' is called not with full path, just as 'cc'. So, if by any chance the UWIN 'cc' gets into $PATH _before_ /usr/bin (this is where Linux 'cc' resides), it will be called, and will fail. The subject says it's just a wild guess - I haven't yet found the wrapper 'cc' source in the source tarball, so I have no idea whether it will even be built under a UNIXish system. > > > > Thanks, > > Sergei. > > > > David Korn > [email protected] > Thanks, Sergei. _______________________________________________ uwin-users mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/uwin-users
