[Scons-users] Trouble Finding GCC

[Waqar, Faaiq G]

Thank you for the explanation. So I added the detection line (print(main.Detect(['gcc', 'clang']))) after I first initialize "main", which returns 
Apptainer> scons build/X86_MESI_Two_Level/gem5.fast
scons: Reading SConscript files ...
gcc

Which I am understanding as it finding the gcc tool without issue. So then, when the SConscript moves onto the the main.Tool call, It still fails. I noticed a few more note placed in this thread, which I haven't replied to but will acknowledge. Indeed the SConscript setup I have is directly from Gem5, and it does work for most folks if not all folks, including myself on other systems. However, in the process of setting this up on my university's HPC, we encountered this issue leaving both IT and myself slightly puzzled.

So to address the finding above, it detects the tool, and then fails due to the nonetype issue once again ("TypeError: 'NoneType' object is not callable: ... SConstruct", line 192:
    main.Tool(SCons.Tool.FindTool(['gcc', 'clang'], main))
  File "/usr/lib/python3/dist-packages/SCons/Environment.py", line 2033:
    tool(self)")
Any thoughts on this. I am reading into the Environment.py file to understand the cause. Thanks for the insight

-----Original Message-----
From: Mats Wichmann <mats at wichmann.us> 
Sent: Monday, September 16, 2024 2:23 PM
To: Waqar, Faaiq G <faaiq.waqar at gatech.edu>; SCons users mailing list <scons-users at scons.org>
Subject: Re: [Scons-users] Trouble Finding GCC

[You don't often get email from mats at wichmann.us. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

On 9/16/24 12:06, Waqar, Faaiq G wrote:
> Thank you for your response, and making me aware of this question from the FAQ.
> So the gcc I am using is located in is /usr/bin/gcc. I added the following lines to my SConscript based my rudimentary understanding of the FAQ solution:
>
> main = Environment(tools=[
>          'default', 'git', TempFileSpawn, EnvDefaults, MakeActionTool,
>          ConfigFile, AddLocalRPATH, SwitchingHeaders, TagImpliesTool, Blob
>      ])
>
> ->main.AppendENVPath('PATH', '/usr/bin/gcc')
> ->main.Tool("gcc")
>
> main.Tool(SCons.Tool.FindTool(['gcc', 'clang'], main)) 
> main.Tool(SCons.Tool.FindTool(['g++', 'clang++'], main))
>
> I am still running into the issue, I assume because I am not using 
> this correctly. Any advice? Thank you again for your time
/usr/bin should be part of the default path. The default path on POSIX-like systems is:

env['ENV']['PATH'] = '/usr/local/bin:/opt/bin:/bin:/usr/bin:/snap/bin'

I think there's possibly a terminology overload here...  the Tool() method loads what SCons calls a Tool Specification Module - which does setup so that you can go ahead and use the actual underlying program.
It happens that the tool modules for the binaries named gcc and clang use the same names...  but you don't want to pass the path to the binary, like /usr/bin/gcc, to Tool, you want SCons to find the tool module itself, which will be in a path like [path-to-SCons]/SCons/Tool/gcc.py.  (g++ has a tool named gcc and
clang++ has one named clangxx, because a '+' is not valid in a Python
module name).

The "public API" for finding a tool is env.Detect() (well, main.Detect(), which you shouldn't even have to use, but as an experiment you could run:

print(main.Detect(['gcc', 'clang'])

and see if it finds either of those - it just returns the name, not the path.