[Scons-users] Strange intel fortran compiler issue.

Mats Wichmann mats at wichmann.us
Sat Nov 9 10:21:45 EST 2024


On 11/8/24 14:37, Peter Diener wrote:
> Hi all,
> 
> Sorry about the lengthy e-mail. Feel free to ignore if you're not 
> interested in scons and Fortran. After Mats reply (thank you Mats) to my 
> last e-mail, I did a bit more digging.
> 
> On Wed, 30 Oct 2024, Mats Wichmann wrote:
> 
>> On 10/30/24 09:49, Peter Diener via Scons-users wrote:
>>>  Hi all,
>>>
>>>  I have just encountered a very perplexing issue with SCons when 
>>> compiling
>>>  a Fortran code (with a few C++ files) on a Linux cluster I have gotten
>>>  access to.
>>
>>>  while I run scons -Q --tree=prune -n -f SConstruct.intel
>>>
>>>  I get:
>>>
>>>  Evaluating SConstruct.intel
>>>  Evaluating module_sudoku.f90
>>>  Evaluating reveal.f90
>>>  Evaluating /sw/compiler/rrz-wrapper/oneapi-2024.2.1/ifx
>>>  Evaluating reveal.x
>>>  ifx -o reveal.x -g reveal.f90 module_sudoku.f90
>>>  Evaluating .
>>>  +-.
>>>     +-SConstruct.intel
>>>     +-module_sudoku.f90
>>>     +-reveal.f90
>>>     +-reveal.x
>>>       +-reveal.f90
>>>       +-module_sudoku.f90
>>>       +-/sw/compiler/rrz-wrapper/oneapi-2024.2.1/ifx
>>>
>>>  showing that scons does not find the dependency on the module.
>>
>> not just the module, the object files are missing, too.
>>
>> yes, this is odd looking.  don't actually expect the OneAPI compilers 
>> to work at all, there's a tracking issue on that - the whole OneAPI 
>> setup depends heavily on environment variables having been set, and 
>> you've only fixed for PATH - in kind of a brute-force way, by 
>> importing all of it.
>>
>> There are some known issues with Fortran modules where the dependency 
>> is not built correctly, mainly if you're using a variantdir (which 
>> you're not). Since the same setup works on a different build host, 
>> that seems unlikely to be what you're running into.
>>
>> Maybe 2024 got even stricter about needing certain env vars than 2022, 
>> but that shouldn't cause SCons to fail to build the tree, since that 
>> process doesn't involve invoking the compiler.
> 
> First of all, I tested whether it was an environment issue by exporting 
> the whole environment instead of just the PATH. That had no effect.
> 
> Secondly I added a couple of print statement in Executor.scan_sources. 
> The first to just make sure that it was called and the second to print 
> out which scanner it was called with. I also added a print statment on 
> entry to Executor.scan as well as print statments for the nodes in the 
> nodelist. Finally I added a print statement on entry to the Fortran 
> scanner. Running this on the machine that works I get:
> 
> scons: Reading SConscript files ...
> scons: done reading SConscript files.
> scons: Building targets ...
> executor.scan_sources called
> executor.scan: scanner =  None
> executor.scan called
> executor.scan: node =  .  scanner =  DirEntryScanner
> Evaluating SConstruct.intel
> Evaluating module_sudoku.f90
> executor.scan_sources called
> executor.scan: scanner =  SourceFileScanner
> executor.scan called
> executor.scan: node =  module_sudoku.f90  scanner =  SourceFileScanner
> Fortran scanner called
> Evaluating /home/packages/compilers/intel/compiler/2022.0.2/linux/bin/ifx
> Evaluating module_sudoku.o
> Evaluating sudoku.mod
> ifx -o module_sudoku.o -c -g -module . module_sudoku.f90
> Evaluating reveal.f90
> executor.scan_sources called
> executor.scan: scanner =  SourceFileScanner
> executor.scan called
> executor.scan: node =  reveal.f90  scanner =  SourceFileScanner
> Fortran scanner called
> Fortran scanner called
> Evaluating reveal.o
> ifx -o reveal.o -c -g -module . reveal.f90
> executor.scan_sources called
> executor.scan: scanner =  None
> executor.scan called
> executor.scan: node =  reveal.o  scanner =  None
> executor.scan: node =  module_sudoku.o  scanner =  None
> executor.scan called
> executor.scan: node =  reveal.x  scanner =  ProgramScanner
> Evaluating reveal.x
> ifx -o reveal.x -g reveal.o module_sudoku.o
> executor.scan_sources called
> executor.scan: scanner =  None
> executor.scan called
> executor.scan: node =  .  scanner =  DirEntryScanner
> Evaluating .
> scons: done building targets.
> 
> while on the machine where it doesn't work, I get:
> 
> scons: Reading SConscript files ...
> scons: done reading SConscript files.
> scons: Building targets ...
> executor.scan_sources called
> executor.scan_sources: scanner =  None
> executor.scan called
> executor.scan: node =  .  scanner =  DirEntryScanner
> Evaluating SConstruct.intel
> Evaluating module_sudoku.f90
> Evaluating reveal.f90
> executor.scan_sources called
> executor.scan_sources: scanner =  None
> executor.scan called
> executor.scan: node =  reveal.f90  scanner =  None
> executor.scan: node =  module_sudoku.f90  scanner =  None
> executor.scan called
> executor.scan: node =  reveal.x  scanner =  ProgramScanner
> Evaluating /sw/compiler/rrz-wrapper/oneapi-2024.2.1/ifx
> Evaluating reveal.x
> ifx -o reveal.x -g reveal.f90 module_sudoku.f90
> scons: building terminated because of errors.
> 
> The glaring difference is that Executor.scans_sources are not called on
> module_sudoku.f90 at all and when it is called on reveal.f90 the scanner 
> argument is set to None.
> 
> Any ideas what could cause this?
will try to get a look at this, might be a little while, sorry.



More information about the Scons-users mailing list