From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Wed, 7 Jun 2006 23:42:12 -0700 From: Roman Shaposhnik Subject: Re: [9fans] gcc on plan9 In-reply-to: <44873F72.7070301@lanl.gov> To: Fans of the OS Plan 9 from Bell Labs <9fans@cse.psu.edu> Message-id: <4487C6C4.5000500@sun.com> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=KOI8-R Content-transfer-encoding: 7BIT References: <200606071058.35174.corey_s@qwest.net> <20060607182441.GF28313@submarine> <44871FF4.2090301@lanl.gov> <20060607190558.GG28313@submarine> <4487337C.7050402@lanl.gov> <20060607204807.GG29458@submarine> <44873F72.7070301@lanl.gov> User-Agent: Thunderbird 1.5.0.2 (X11/20060420) Topicbox-Message-UUID: 60662e0e-ead1-11e9-9d60-3106f5b1d025 Ronald G Minnich wrote: > IMHO, you know more than I do at this point! Relatively speaking ;-) I once tried to do the same thing I do with these 500+ apps with everything that's available through the Gentoo portage system. To say that I was surprised would be a gross understatement. :-( > So, what's our problem :-) Is all hope lost? > Is this mess fixable? If so, how? Now that I understand your goal (which is to provide a way for running a preselected set of HPC apps on a Plan9 system) and I can stop confusing it with inventing a magic G-wand I'd say that your biggest challenge will be to carefully retarget the apps in question from (L)POSIX/C++ environment. I don't believe its a lost cause, but it all depends on how messy the apss will turn out to be. I don't know much about the apps, but here's a list of issues I personally confronted while porting Sun Studio C/C++ compiler from Solaris to Linux: It doesn't matter whether its C, C++ or Fortran -- nowadays its all about autotools/libtool recognizing your system, and let me tell you these guys are *wild*. Case in point: when we first ported our seed C compiler autoconf was convinced that it was a PGI compiler running on an Open?BSD system -- go figure. Once you get past configuring the apps, every C/C++ compiler gets confronted with two essential interfaces: glibc and linker/ELF. For a C compiler dependency on ELF is less of an issues, but for a C++ one its a pretty big deal. In fact we had seriously considered porting Solaris ld to Linux just so that we don't have to depend on GNU ld messing up object files (we ended up fixing GNU ld, but its a different story). Next comes the glibc, which in turn, depends on Linux kernel headers and wants to get into compiler business all the time by providing "kosher" crt*.o and demanding a certain way of tickling its internals for things like IEEE floating point support to work properly. The biggest problem with all of this is that the way C99 (and portions of the C++) standard are structured makes it impossible to have a properly functioning application unless you have glibc support in certain areas. One of the reasons GCC can't claim C99 compliance is because glibc sucks (you can find more on that right here: http://gcc.gnu.org/gcc-4.1/c99status.html). Now, you say that you're going to use APE and there I have serious doubts that things like FP exception handling and C99 complex will work for you. These two proved to be quite essential for the set of HPC apps I have internally from *our* customers. Now, suppose that you've overcome all of that. What's next ? C++ of course! C++ with things like templates instantiations in ELF COMDAT sections and exception handling support places lots of additional requirements on how flexible linker should be in handling ELF files. Speaking of which -- do you intend to port ELF to Plan9 as well ? Once you get past codegeneration the glibc will rear its ugly head once again. This time around it'll be about supporting C++ header files which are just there to wrap around standard C headers in the latest and greatest std:: namespace. Of course, I'm talking about things like and . There again you will start battling how gcc configures itself on different systems and how it all can be hooked up to APE. Oh, and there's also a question of what to do about MT apps. I'd be very curious to know how would you go about solving it on Plan9 as far as PTHREADS are concerned. Or may be your apps don't use any (which I find hard to believe for an HPC market). That's about it when it comes to the biggies. The sort of things I distinctly remember suffering through on a personal level. On the application level you still have to tame dependencies on things which go beyond the scope of C99 or ISO C++ standards, but that's a story for another day. >> Well, all I can say is -- its a pity that even more resources will >> be spent on proliferating gcc's bad influence on application >> developers. > > The world sucks. I could not agree more. Propagating all this gnu > stuff is depressing, makes me wish I did something else for a living > sometimes. I sort of watch with amazement as people work on the > segment layout of their ELF files, and discuss what to inline. arg! > > thanks, I think you've educated me (I'm dead serious). Well, I'm glad my emails weren't in vain. I'm very curious to see how far you can go with the approach you've chosen, and I'd be glad to share more of the porting experience. Feel free to drop me emails on this subject. I've been there and there's a chance I might be able to help you guys. Thanks, Roman.