[Home]

Summary:ASTERISK-08939: [patch] Zaptel build no longer honours HOSTCC
Reporter:Tony Mountifield (softins)Labels:
Date Opened:2007-03-05 10:14:27.000-0600Date Closed:2011-06-07 14:08:18
Priority:MinorRegression?No
Status:Closed/CompleteComponents:Core/General
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) zaptel-1.2-Makefiles-v2.diff
Description:Starting with revision 1206, the Makefile no longer honours the HOSTCC variable, which is necessary on some systems where the kernel is built using a different version of gcc from the default. Fedora Core 1 is one example, where HOSTCC=gcc32 should normally be specified to ensure the driver modules are built using the same version of gcc as the kernel.

On FC1, building the modules using cc or gcc instead of gcc32 results in many compiler warnings such as the following:

cc -I/lib/modules/2.4.22-1.2199.nptl/build/include -O6 -DMODULE -D__KERNEL__ -DEXPORT_SYMTAB -I/lib/modules/2.4.22-1.2199.nptl/build/drivers/net -Wall -I. -Wstrict-prototypes -fomit-frame-pointer -I/lib/modules/2.4.22-1.2199.nptl/build/drivers/net/wan -I/lib/modules/2.4.22-1.2199.nptl/build/include/net -DMODVERSIONS -include /lib/modules/2.4.22-1.2199.nptl/build/include/linux/modversions.h   -DSTANDALONE_ZAPATA -o zaptel.o -c zaptel.c
In file included from /lib/modules/2.4.22-1.2199.nptl/build/include/asm/semaphore.h:39,
                from /lib/modules/2.4.22-1.2199.nptl/build/include/linux/fs.h:202,
                from /lib/modules/2.4.22-1.2199.nptl/build/include/linux/capability.h:17,
                from /lib/modules/2.4.22-1.2199.nptl/build/include/linux/binfmts.h:4,
                from /lib/modules/2.4.22-1.2199.nptl/build/include/linux/sched.h:10,
                from /lib/modules/2.4.22-1.2199.nptl/build/include/linux/mm.h:4,
                from /lib/modules/2.4.22-1.2199.nptl/build/include/linux/slab.h:14,
                from /lib/modules/2.4.22-1.2199.nptl/build/include/linux/proc_fs.h:5,
                from zaptel.c:46:
/lib/modules/2.4.22-1.2199.nptl/build/include/asm/system.h: In function `__set_64bit_var':
/lib/modules/2.4.22-1.2199.nptl/build/include/asm/system.h:189: warning: dereferencing type-punned pointer will break strict-aliasing rules
/lib/modules/2.4.22-1.2199.nptl/build/include/asm/system.h:189: warning: dereferencing type-punned pointer will break strict-aliasing rules

The attached patch for Makefile and wct4xxp/Makefile restores the correct usage of HOSTCC when building kernel modules.

****** ADDITIONAL INFORMATION ******

The same issue probably applies to branch 1.4 and trunk too, but I haven't checked.
Comments:By: Tony Mountifield (softins) 2007-03-05 10:36:23.000-0600

Hmm, there's evidently more to it than just HOSTCC, because although zaptel now appears to build correctly, trying to load it results in the following:

/lib/modules/2.4.22-1.2199.nptl/misc/zaptel.o: unresolved symbol main
/lib/modules/2.4.22-1.2199.nptl/misc/zaptel.o: unresolved symbol __fini_array_start
/lib/modules/2.4.22-1.2199.nptl/misc/zaptel.o: unresolved symbol __fini_array_end
/lib/modules/2.4.22-1.2199.nptl/misc/zaptel.o: unresolved symbol __init_array_start
/lib/modules/2.4.22-1.2199.nptl/misc/zaptel.o: unresolved symbol __preinit_array_end
/lib/modules/2.4.22-1.2199.nptl/misc/zaptel.o: unresolved symbol __init_array_end
/lib/modules/2.4.22-1.2199.nptl/misc/zaptel.o: unresolved symbol _GLOBAL_OFFSET_TABLE_
/lib/modules/2.4.22-1.2199.nptl/misc/zaptel.o: unresolved symbol __preinit_array_start
/lib/modules/2.4.22-1.2199.nptl/misc/zaptel.o: insmod /lib/modules/2.4.22-1.2199.nptl/misc/zaptel.o failed
/lib/modules/2.4.22-1.2199.nptl/misc/zaptel.o: insmod zaptel failed

I'll continue to investigate, but if anyone recognises the above errors and knows the correct fix, please post.
By: Tony Mountifield (softins) 2007-03-05 11:04:10.000-0600

OK, silly error on my part, changing $(LD) as well as $(CC).

v2 patch uploaded which compiles correctly on my system and the modules load successfully.

Please could a bug marshall delete the first patch? Mantis offered me a "Delete" link, but when I clicked on it, it said "Access denied". Go figure.
By: Tzafrir Cohen (tzafrir) 2007-03-07 01:26:41.000-0600

zaptel-base.o on kernel 2.4 should not be built with HOSTCC ;-) .

Also: is there any need to explicitly pass VAR="$(VAR)" in a call to a recursive make?

And you probably also missed the explicit setting of HOSTCC to gcc. I don't think that this is a good idea.
By: Tony Mountifield (softins) 2007-03-07 02:36:26.000-0600

1. Why shouldn't zaptel-base.o be built with HOSTCC? It is part of the zaptel kernel module, and zaptel.o was always built with HOSTCC before rev 1206. It has only been separated out into zaptel-base so it can be linked with HPEC. I can see there may be a problem if the closed-source HPEC was built with a different compiler, but I think that issue should be addressed separately, and not just by building the zaptel module with the wrong gcc for the kernel in use.

2. Yes, I found HOSTCC="$(HOSTCC)" was necessary. Unless all variables were exported to the environment, and then imported from the environment by the child Makefile, this is to be expected, isn't it?

3. The Makefile has always contained HOSTCC=gcc. I change it to HOSTCC=gcc32 myself when building on FC1.

I'm sure most of the above ceases to be relevant on more recent systems that use kernel 2.6, but the point of my patch was to retain the compatibility with earlier versions that had (I assume) been lost accidentally rather than deliberately.


By: Tzafrir Cohen (tzafrir) 2007-03-07 03:00:29.000-0600

1. HOSTCC is used for building code that should be run on the host system. e.g: makefw that is used at build time by the building computer.
By: Tony Mountifield (softins) 2007-03-07 03:15:21.000-0600

I think you misunderstand. In the zaptel Makefile, HOSTCC defines the compiler used to build kernel modules, which should be the same as that used to build the kernel itself. This was the case until major changes at revision 1206, at which point the build rule for modules was accidentally changed to use $(CC) instead of $(HOSTCC).
By: Russell Bryant (russell) 2007-03-07 10:10:23.000-0600

Well, if that used to be the case, it was wrong.  Regardless of what it used to be, the intended behavior is that HOSTCC is used to build things that are to be executed on the host system, the one you are doing the build on.

It is correct to use CC for building kernel modules.  CC is what is supposed to be used for building for the target system, which may or may not be the same as the host system.
By: Tony Mountifield (softins) 2007-03-07 10:31:53.000-0600

Russell, you are mistaken. Please could you refer this question back to someone like Mark, Jim or Kevin who knows the long-term history?

Whatever you believe HOSTCC should be intended for, it was originally used in the Zaptel makefile to specify the compiler used to build kernel modules, on those systems (like FC1) that used a different compiler than that used to build user-space programs ($(CC)). This worked perfectly well prior to revision 1206.

We're NOT talking about cross-compilation here! And I DO know what I'm talking about (sigh). The distinction is between kernel-space and user-space on the same system.

I suspect it is this misunderstanding that caused the correct behaviour to be broken at revision 1206 onwards.

I don't care whether it gets called HOSTCC, KCC or whatever, but its definitely not right on some systems just to use CC.


By: Tzafrir Cohen (tzafrir) 2007-03-07 11:44:45.000-0600

softins: what version of gcc do you use?

As we see, on your system a certain build command has failed to build the zaptel kernel modules whereas another one has succefully built them. What was the "good" command and what was the "bad" command?
By: Russell Bryant (russell) 2007-03-07 12:29:39.000-0600

It is absolutely not correct to use HOSTCC for building the kernel modules.  This patch will not be applied.

If you need to specify a different compiler for the kernel modules, then set CC.  The userspace applications will be built using CC as well, but that is perfectly fine.