So my company is not likely to allow me to use G++ anytime soon so the only C compiler I have access to at work is MSVC. I am attempting to use the following code to point pytensor to the compiler with a glaring issue that keeps cropping up. Running the following code:
And then running a simple model, I get the following as part of my error messages:
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.29.30133\bin\HostX86\x86\cl.exe -shared -g -O3 -fno-math-errno -Wno-unused-label -Wno-unused-variable -Wno-write-strings -Wno-c++11-narrowing -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables -DNPY_NO_DEPRECATED_API=NPY_1_7_API_VERSION -m64 -DMS_WIN64 -I"c:\Users\WYoung1\AppData\Python.venv\Lib\site-packages\numpy\core\include" -I"C:\Program Files\Python312\include" -I"c:\Users\WYoung1\AppData\Python.venv\Lib\site-packages\pytensor\link\c\c_code" -L"C:\Program Files\Python312\libs" -L"C:\Program Files\Python312" -o “C:\Users\WYoung1\AppData\Local\PyTensor\compiledir_Windows-10-10.0.19045-SP0-Intel64_Family_6_Model_186_Stepping_2_GenuineIntel-3.12.3-64\tmp0zbh_sn_\mfeba4d434591def33153ec442edc27a735fd9fa46fd5f1fae8efd4f490539b0a.pyd” “C:\Users\WYoung1\AppData\Local\PyTensor\compiledir_Windows-10-10.0.19045-SP0-Intel64_Family_6_Model_186_Stepping_2_GenuineIntel-3.12.3-64\tmp0zbh_sn_\mod.cpp” “C:\Program Files\Python312\python312.dll”
‘C:\Program’ is not recognized as an internal or external command,
operable program or batch file.
From what I can tell observing this issue, the following is happening:
1.pytensor is asking for complier flags in the syntax of g++
2. pytensor may not understand that I am pointing it to another compiler
3. While I am aware my attempt to add cxxflags did not include linking folders, I was testing cxxflags I submitted would be picked up by PYTENSOR at all and the fact that they did not is indicative of a problem.
Does anyone have advice on how to handle this situation–without changing compilers or adding additional packages as that would be at least 6 months of waiting for my IT department to consider if they would allow that.
@lucianopaz after removing the space between program and files, it picked up the full path for the c complier but as the “Program Files” folder has a space in the name, it cannot find the file path.I finally had to put a single quote around the double quoting of the path to the complier to get it to interpret everything correctly. After running the following:
The error messages are saying it is failing to compile with the error message cl : Command line error D8021 : invalid numeric argument ‘/Wno-unused-label’ This is something that I saw referenced in the original error message before I made my inputs to pytensor.config.cxxflags. Calling that function now returns only what I would expect which is
So it seems progress is being made but it for some reason, that flag which is no longer showing in pytensor.config.cxxflags is still making an appearance at execution.
Create a subclass of CLinker that overloads the compile_args method so that it doesn’t use those extra flags. I don’t know how to get that linker to be used later though. Maybe @ricardoV94 can help with that.
You could monkey-patch the pytensor.CLinker class to overload its compile_args method. The catch is that you have to monkey-patch it right after importing pytensor, and if you forget doing it in time, you’ll get the wrong flags again.
Edit the pytensor code locally so that it doesn’t add those flags. This would be the worse case scenario, but maybe you could try it out to see if options 1 or 2 will actually allow your code to work.
I don’t know if pytensor itself should be able to detect any C compiler’s valid arguments, but if it should, it’s worth opening an issue on GitHub.
@lucianopaz thank you for this, I’ll check this solution but I am just wondering how I access the the CLinker class–I have not tried to access the this many layers deep into a module before and I am unclear how to direct python towards the Clinker from code I am writing. For example I tried pytensor.link.c.basic and was told the module did not exist.
I understand. It’s not easy to do, and doing something like the first two points that I mentioned would involve some advanced coding skills. To be able to import the CLinker, you’ll have to do something like:
from pytensor.link.c.basic import CLinker
but getting the c mode use a monkey patched version of the linker, or building a new mode with a subclass of the linker is a whole other level.
The third point is easier. You just need to use an editor to open the pytensor/link/c/basic.py file from where you installed pytensor, remove the compilation flags and save the file. After that, you can try if your simple model works.
Up until now we’ve only focused on trying to make things work with msvc, which pytensor doesn’t do out of the box, and is uncharted territory. Maybe you could explore the possibility of accessing the windows subsystem for linux (WSL). If you can use that, it would make using pymc much simpler. Maybe @fonnesbeck can weigh in on how that looks like.
Alternatively @Wesley_Young you can try to avoid the C backend altogether, by setting pytensor.config.mode = "NUMBA" after importing PyMC, or using external nuts sampler nutpie (numba backend) or numpyro/blackjax (jax backend)
@lucianopaz So I was able to access the cLinker definition and rewrite them to suite MSVC but additional flags that are not present in Clinker are appearing when I check the error message. these flags are -Wno-c++11-narrowing -fno-exceptions -fno-unwind-tables -fno-asynchronous-unwind-tables . Any idea where these could be coming from?
@ricardoV94 even if I just import nutpie and try to use nutpie.compile_pymc_model directly without calling on pytensor, it acts as if I tried to sample using pytensor and I end up with the same c errors.
@ricardoV94 that worked and looking at the code, the option is there, the documentation is just confusing as it seems to omit that NUMBA global variable. Thank you. Not yet marking this as a solved only because I am curious to see if the c complier issue can be resolved as well. But this is definitely viable if that wont work.
If I do the same but run pytensor.config.gcc__cxxflags =‘“”’ then the -m64 error is dropped and in its place is the error cl : Command line warning D9024 : unrecognized source file type ‘’, object file assumed.