Opened 19 years ago
Last modified 18 years ago
#10 reopened defect
parallel compilation problem on Linux
Reported by: | Owned by: | arnault | |
---|---|---|---|
Priority: | high | Milestone: | |
Component: | a. Usage | Version: | v1r18 |
Severity: | normal | Keywords: | |
Cc: | Pere.Mato@… | OS: | All |
If Other, could you precise: | Experiment: | Atlas | |
If Other, could you precise: | |||
Stack trace: | |||
Steps to reproduce: |
Description
When trying to compile the Gaudi framework using the distcc program for distributed compilation, a problem appears on Linux.
While on windows the objects files are created in a separate directory for each constituent:
win32_vc71/GaudiAlg/*.obj
win32_vc71/GaudiAlgLib/*.obj
this is not the same behavior for the Linux version. The files are all created in the same directory:
slc3_gcc323/*.o
If there is the same file name in 2 constituents in the same package, the parallel compilation could try to write both at the same time in the slc3_gcc323 directory and thus fail.
Moreover the problem could still appear without parallel compilation. For example if one creates 2 test applications (test1.exe and test2.exe) in the same package:
src/test1/main.cpp
src/test1/hello.cpp
src/test2/main.cpp
src/test2/hello.cpp
with the rules:
application test1.exe src/test1/*.cpp
application test2.exe src/test2/*.cpp
After the creation of the test1.exe executable, the Makefile doesn't need to recreate main.o and hello.o in the slc3_gcc323 directory and may reuse them to create test2.exe. Could it be possible to have the same behavior as on windows? i.e. to have separate directories:
slc3_gcc323/test1/*.o
slc3_gcc323/test2/*.o
Change History (2)
comment:1 Changed 18 years ago by
Resolution: | → fixed |
---|---|
Status: | new → closed |
comment:2 Changed 18 years ago by
Experiment: | → Atlas |
---|---|
OS: | → All |
Priority: | normal → high |
Resolution: | fixed |
Status: | closed → reopened |
Version: | v1r16 → v1r18 |
Actually developpers are complaining about this solution to the problem: they would like to have an option in a requirements defining the strategy (with or without structured output) and not typing every time the "make STRUCTURED_OUTPUT=1" on the command line.
The problem is particularily severe when new projects are converted to the CMT build system. Many files can have the same name in one package for different components and overwrite eachothers file.
This is resolved on the linux platform in the next cmt release v1r18p20060606. To be atlas compliant, this strategy is not built by default you should called explicitely the STRUCTURED_OUTPUT option, e.g. make STRUCTURED_OUTPUT=1