[OpenAFS-devel] configure not honoring 'CC' environment variable

[Jeffrey Hutzelman]

On Wednesday, March 16, 2005 10:50:31 PM -0600 Troy Benjegerdes 
<hozer@hozed.org> wrote:

> On Wed, Mar 16, 2005 at 07:57:18PM -0500, Jeffrey Hutzelman wrote:
>>
>>
>> On Monday, March 14, 2005 11:27:08 AM +0100 Harald Barth
>> <haba@pdc.kth.se>  wrote:
>>
>> >
>> >> (e.g. most Solaris versions need the C compiler  from
>> >> the SUNWspro suite).
>> >
>> > I wrote configure 2 tests a long time ago which test if the Solaris or
>> > the AIX compiler are "good enough". Still waiting for them to be used.
>> >
>> > According to my view of things, folks setting CC should know what they
>> > do and the makefiles should not override it. For folk _not_ setting
>> > CC the makefiles can do what they figure is best.
>>
>> Unfortunately, this is pretty hard to get right, because once the
>> AC_PROG_CC test has run, there is really no way to tell if the resulting
>> value of CC came from the user or from the test.  And it's pretty hard
>> to  get AC_PROG_CC not to run.
>>
>> Further, I don't think it's reasonable to assume that folks setting CC
>> on  configure's command line understand the kernel compiler issue, or
>> that  people who do understand the issue necessarily want to override
>> the kernel  compiler whenever they set CC to select a userland compiler.
>
> I don't think it's reasonable to assume that 'cc' is what you want to
> build with. If folks can't set CC, they will go hack the makefiles
> directly.

Maybe you're not reading the same thread I am.  I didn't say users 
shouldn't be able to override the compiler; I said it was hard to get it 
right, particularly with the behaviour haba described.  If it were easy, 
it'd have already been done, and we wouldn't be having this conversation.

Harald suggested that if a user sets CC on the command line, we should 
assume they know what they are doing.  As I explained, there are two 
problems with this:

- It is impossible for the Makefiles, or even most of the configure tests,
  to tell the difference between a value of CC that was set on the command
  line and one that was set by AC_PROG_CC
- It is a bad idea to assume that a user who sets CC on the command line
  "knows what they are doing" and expects to use that compiler to build
  the kernel module, because they probably don't know what they're doing
  wrt the kernel compiler issue, and if they do, they probably don't want
  to use that compiler for the kernel module.


> The kernel compile better be using the compiler the kernel was built
> with. In the case of Linux, I think this is all handled with the kernel
> makefiles.

Actually, the Linux makefiles generally assume you want to use 'gcc' unless 
you specify something else on the command line.  This often turns out to be 
the right choice, but not always.

And of course, OpenAFS is a multi-platform software package, not a 
Linux-2.6-specific one, so even if kbuild solved the problem, that wouldn't 
excuse us from dealing with it on AIX and Solaris and HPUX and Linux 2.4.


> This issue would be a lot easier to sort out if the kernel and userland
> code were clearly separated. Or at least the build process. Is there
> documentation or whitepapers that I can look up at what afsd actually
> does before handing off control to libafs in the kernel? I'm wondering
> why both afsd and libafs are so big.

You can read src/afsd/afsd.c; it's actually a fairly simple program.  I'm 
not sure why you believe afsd is 'big'; mine is all of 168K.


> What happens if I have a 32 bit userland, and a 64 bit kernel, for
> example. So far I've always punted and built all of afs 64 bit.

With the exception of afsd, we are rapidly approaching the point where 
32-bit userland tools can be expected to work on most of the 64-bit Linux 
platforms.  As of the 1.3.80 release due out shortly, I expect this will 
work for any process using the /proc interface (wihch is the case for 
anything linked against a reasonably modern version of either the OpenAFS 
libraries or KTH's libkafs), and for processes using the syscall interface 
on those architectures where we successfully locate and patch the secondary 
32-bit syscall table.  You will be able to tell if this works by looking at 
dmesg output after loading the libafs module; it print either the address 
of the 32-bit syscall table, or a message indicating it could not be 
located.

There is currently no guarantee that a 32-bit afsd will work with a 64-bit 
kernel.  For this to work, the kernel code would have to translate some of 
the data structures passed in by a 32-bit afsd, and I don't believe the 
analysis has been done to determine which structures are affected and make 
sure they are handled.

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA