It seems weird. If I remove it, I stop getting the error. I did a bit of shallow searching through the cmake repo. Nothing seems wrong with AddSymbolExportCommand(...). I notice the call to this->GeneratorTarget->GetPreLinkCommands() right before the usage of AddSymbolExportCommand. I assume that’s where the “C:” is being added. I searched for calls to AddPreLinkCommand and found all the AddCustomCommandToTarget calls and at that point I think I’m out of my depth.
I’m on Windows 10, I just upgraded to Visual Studio Build Tools 2022 17.1.6. I’m using cmake 3.23.1 installed from chocolatey. That’s the same one being used by the vcproj command (C:\Program Files\CMake\bin\cmake.exe).
Note: after getting past this error, I start getting errors about ‘unresolved external symbol "__declspec(dllimport)’, (my cli target not being able to link to my shared library target) but I think that’s just a problem with my setup that I need to figure out.
I suspect that somewhere is a path with \ that escapes the first character after it and confuses things. Are there any \-using paths in your cache file?
I changed the line the CMakeCache.txt file to use forward slashes and I still got the “C:” line in the vcxproj command element. I’m assuming I shouldn’t (or in other cases just can’t) change the cmake files I see in the --trace-expand log that are not defined in my own project. Let me know if there’s anything specific I should try with respect to this.
Remember how I said that when I remove that “C:” line from the vcxproj command element, I stop getting the command error, but then I get errors saying that when building my cli target, it can’t resolve the symbols from my library target? There’s something new I noticed: I just opened the exports.def file that got created and it’s empty. When I try manually running the pre-link command that cmake is trying to run:
It exits with segfault and no other message. Nothing seems wrong about the contents of my objects.txt file. It lists full paths to the object file of my project.
whoops. I got a reply autoremoved because I was editing it too much and it got filtered as spam. It should be back once reviewed. Sorry about that. Continuing on what I was saying there, though, I may have found a bug? when I manually run the cmake -E __create_def command the first time, it exits with SegFault. But if I run it again, it runs fine and then creates and empty file (which also isn’t what I expect, but at least it doesn’t segfault). Turns out it segfaults if the exports.def file isn’t already created. The first run that segfaults creates the file, and then the second run finds the file already existing.
Note: The generator I’m using is “Visual Studio 17 2022”. I don’t think that’s related to the problem. I wonder if it could possibly be this line in cmcmd.cxx that gets something time-related to the exports.def file. Maybe it’s expecting it to exist and not handling the case of it not existing?
I’m just going to add replies instead of editing old ones now.
Okay so I tried creating an empty exports.def file with a timestamp older than all the object files, and that also results in a segfault. It’s not only if the file doesn’t exist yet. It also exhibits the behaviour of no longer segfaulting (but still creating an empty file) the second time, since I guess the first time still changes the modification time of the file.
Ah. I think the segfault is certainly worth a new issue at least. I’m not familiar enough with the create_defs bit to know whether nm is essential or not (probably is?).
