-
Notifications
You must be signed in to change notification settings - Fork 341
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cmake/utils.cmake doesn't properly quote arguments to "ar" #473
Comments
Hmm, I should point out that this patch doesn't touch the "MSVC" or "APPLE" versions of output. I assume they'd need similar changes, but am not familiar with either environment. |
Thanks for the good bug report and suggested solution. I think this flow is used on OSX but not on Windows. OSX uses Bash as well, so this solution will work. |
Actually, I see the MSVC case there too. I tried your solution and it doesn't seem to work when the directory name has spaces in it. |
Ugh, you are correct. I thought I had fixed the problem, but didn't realize in my quick test I was actually building in a directory w/out "+" or " " in its path :(. After some searching, it looks like this is a problem with the "ar" scripting language. In https://sourceware.org/binutils/docs/binutils/ar-scripts.html#ar-scripts, both the "+" and characters are called out as having special meaning, with no way to escape them. It may be the only way to solve this problem is to call "ar" with command line arguments instead of using "-M". I'll keep playing with it to see if I can come up with a working solution, but the one I submitted at first definitely does not work. |
Ok. Thanks. Yeah, I was thinking a custom_command and associated custom_target would be the way to go. |
So, after much mucking about, it appears that there are only two ways to combine multiple .a static library archives together into a single library. By far, the easiest way is what's being done, writing a MRI script, and running it with "ar -M". The other way is to take each library archive, extract all of the .o files out of it into some temporary directory, then add them all to a new archive with ar from the command line. This method is fraught with peril, as more than one .a may contain .o files of the same name, so symbols could be overwritten and lost. So, I think the only way to fix this is to do it in two steps via some sort of script:
I'll work on such a script. |
OK, this feels like an overly complicated kludge, but I can't figure out any other way to do it. I basically create a shell script which uses "realpath" to output the proper MRI script using relative paths (which hopefully won't contain any special characters). Then I pipe the output of that script into "ar -M". I've been able to successfully build using this patch. One thing I wonder about, but I'm not versed enough in shaderc or cmake to answer it: why is libtool used to build/manipulate static libraries on the mac, but not on linux? Using libtool would seemingly make the problem a lot simpler.
|
This idea could work, however it would not make sense to continue using the MRI script. The MRI script doesn't appear to support any escaping. https://sourceware.org/binutils/docs/binutils/ar-scripts.html
If you are using a list of object files, using an MRI script adds no value. The code probably uses the script currently because it can extract object files from other static libraries in one step. That is not a one-step operation using the ordinary flags. |
Just ran into this issue trying to build and package the latest SuperTuxKart RC (1.4-rc1). What is the recommended fix here to avoid build failures? |
Build it in a path that does not contain any whitespace to avoid the problem. |
This was completed by the PR and can be closed. The fix is available starting in v2023.8. |
When utils.cmake builds a directive file for "ar" as part of building libshaderc/libshaderc_combined.a, it fails to properly quote the arguments to "ar", thus causing "ar" to fail if the build directory happens to contain any characters which might be construed to mean something special on the command line. Here's an example from me trying to build a debian package:
Here is a patch to fix the problem:
The text was updated successfully, but these errors were encountered: