summaryrefslogtreecommitdiffstats
path: root/make/lib.cfg
diff options
context:
space:
mode:
authorJoel Sherrill <joel.sherrill@OARcorp.com>1999-02-24 15:15:29 +0000
committerJoel Sherrill <joel.sherrill@OARcorp.com>1999-02-24 15:15:29 +0000
commit4d20133bef8c892ec3d51b5eb391d4fd892c6e94 (patch)
tree2b0e96faffb1e34f907c66325a2f7267a73f14f2 /make/lib.cfg
parentd6f2820063c66574eade848ba90f162dbb47b4a6 (diff)
downloadrtems-4d20133bef8c892ec3d51b5eb391d4fd892c6e94.tar.bz2
Patch from Ralf Corsepius <corsepiu@faw.uni-ulm.de>. The following email
is long but I hate to lose the information so I am including it here. > I am still fixing and recompiling but this is the issue that was not the > result of another patch. This is a fundamental build issue that I value > your opinion on. This is difficult issue (I.e. I have no destinct solution for it) Background: (gnu-) make's implicit rules apply CFLAGS, CPPFLAGS, CXXFLAGS, ASFLAGS and LDFLAGS (cf. make.info/Implicit Rules/Catalogue of Rules), only. In brief: CPPFLAGS .. passed to the c-preprocessor CFLAGS ... passed to the c-compiler CXXFLAGS ... equivalent to CFLAGS but passed to the c++ compiler (Attention: CFLAGS is not passed to the c++ compiler) ASFLAGS .. equivalent to CFLAGS, but passed to the assembler LDFLAGS .. equivalent to CFLAGS, but passed to the linker A bit oversimplifying, these make rules are as follows .c.o: $(CC) $(CPPFLAGS) $(CFLAGS) -c .cc.o: $(CXX) $(CPPFLAGS) $(CXXFLAGS) -c .S.s: $(CPP) $(CPPFLAGS) .s.o: $(AS) $(ASFLAGS) My reading of the documentation (make.info) is that {AS|AR|CC|CXX|CPP}FLAGS are ment to be passed to the related tools directly, however examinating the rule set of gmake (gmake -p -f /dev/null") shows that many rules use $(CC) instead of the related tools (eg. linker rules) etc. I.e. these flags should not rely on being passed through cpp or gcc. With gcc being the common frontend for all of these tools of a gnu-toolchain the situation becomes difficult (Which option is passed to whom and which tool really uses it?), because these variable can also contain the toolchain's frontend (eg. AS=gcc, LD=gcc, CPP=gcc -E). For some commonly used options the situation is quite clear: * -g -> CFLAGS * -OX -> CFLAGS * -D -> CPPFLAGS * -A -> CPPFLAGS But where to add -m, -B, -specs, -qrtems_XXX ? * -B, -specs, -qrtems_XXX are gcc-frontend options * -m is a combinations of flags to go to different destinations, in many (all?) cases, the following is valid -m is expanded by gcc into a set of -D and -A options -m is interpreted by cc1 as a machine flag to generate a specific instruction set. -m is interpreted by gcc as an implicit linker search path for multilibs to set up calls to LD. >From my point of view this indicates we can either destingush between these different usages (= separately add -m to CFLAGS, LDFLAGS etc) or to add it to CPPFLAGS and use gcc (the frontend) instead of calling each tool directly (less error prone) -- I vote for CPPFLAGS, but I am not sure. ----------------- Now, where to add CPU_CFLAGS? AFAIS, in probably all cases CPU_CFLAGS contain -D -A, and -m options, only. * -D and -A are supposed to go to CPPFLAGS * -mXXX options can have multiple meanings (It can be gcc, collect2/ld and cc1/cc1plus option simultaneously) Here, I made a mistake - I destinguished between CPU_DEFINES to be added to CPPFLAGS and CPU_CFLAGS to be added to CFLAGS and CXXFLAGS (cf. gcc-target-default.cfg), generally assuming CPU_CFLAGS are CFLAGS. This breaks preprocessing *.S into *.i files because CPU_CFLAGS flags were not added to CPPFLAGS. Hence *all* *.S were compiled without taking -mXX-flags into account. The i960/cvme BSP was the only one which explicitly checked for a specific -m flag (-mca) and refused to compile without it -- all other CPUs/BSPs silently swallowed this. IMO, we can either 1) add CPU_CFLAGS and CPU_DEFINES to CPPFLAGS, thus silently convert CPU_CFLAGS's meaning into CPU_DEFINES (Alternative solution: rename CPU_CFLAGS to CPU_DEFINES and merge CPU_FLAGS with CPU_DEFINES). or 2) destinguish between CPU_DEFINES and CPU_CFLAGS. In this case we would need to check the contents of each CPU_CFLAGS in custom/*.cfg and move the some parts of the contents to CPU_DEFINES and keep other parts in CPU_CFLAGS (CFLAGS must contain options for the c/c++-compiler only!). Though Solution 2) is the clearer one, I implemented 1) which is the simplier one (the patch below). ATTENTION: This patch is small in size, but affects almost everything. ------------ Additional complications araise with linking: Some BSPs call LD and AS directly (esp. gcc-2.7 make-exe rules). If LD=gcc then LDFLAGS are supposed to be gcc-options, but if LD=ld then LDFLAGS is supposed to contain ld-options. An analog thought is valid for AS, but luckily enough ASFLAGS is not used of inside the whole source tree. Most RTEMS' custom/*.cfg use $(CC) $(CFLAGS) to link with gcc-2.8 make-exe rules. With the patch below (CPU_CFLAGS added to CPPFLAGS) this means CPU_CFLAGS will not be passed to the linker, which is incorrect for multilibbed CPU's. gmake's default rule set contains a variety of rules for linking, all ending up in calling $(CC) $(LDFLAGS) for linking at their very end. IMO, this means we should use something like LINK.o = $(CC) $(LDFLAGS) in gcc-target-default.cfg + modify all gcc-2.8 make-exe rules to use $(LINK.o) ....... + setup LDFLAGS according to the requirements of the above. I.e. we should use $(CC) for linking instead of calling the linker (LD) directly and set LDFLAGS = $(CPPFLAGS) $(CFLAGS) or similar.
Diffstat (limited to 'make/lib.cfg')
0 files changed, 0 insertions, 0 deletions