| Summary: | error: The command line is too long when building MESA on Windows with MinGW-W64 | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | sav_ix |
| Component: | Other | Assignee: | mesa-dev |
| Status: | RESOLVED MOVED | QA Contact: | mesa-dev |
| Severity: | normal | ||
| Priority: | medium | CC: | sav_ix |
| Version: | git | ||
| Hardware: | x86-64 (AMD64) | ||
| OS: | Windows (All) | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Attachments: | sample of too long command line | ||
|
Description
sav_ix
2016-02-10 04:51:35 UTC
Created attachment 121672 [details]
sample of too long command line
I believe that this issue is not that specific to mesa and/or the build system. I've had similar experience with piglit (which uses cmake). The workaround I used was to use the shortest path possible for the repo and install location (iirc I used e:\p\ and e:\i\ respectively) The mesa MSVC builds have been running fine [1] but I'm wondering if we cannot wire up the mingw/mingw-w64 ones ? [1] https://ci.appveyor.com/project/jrfonseca-fdo/mesa/ > I believe that this issue is not that specific to mesa and/or the build system. Yes, that issue is somewhere between Windows and SCons. More details at https://bitbucket.org/scons/scons/wiki/LongCmdLinesOnWin32 , as I wrote above. > use the shortest path possible for the repo and install location (iirc I used e:\p\ and e:\i\ respectively) I assume that would be acceptable not for all users (Linux users don't have such restrictions). But Mesa builds using MinGW-W64 fails even from e:\p\ directory, because 'ar' utility receive command line with about 12,355 symbols (see attachment above), while Windows limit seems to be 10,000 symbols. > https://ci.appveyor.com/project/jrfonseca-fdo/mesa/ As I understood your sample relates to Mesa builds using LLVM, while my error report relates to builds using MinGW-W64. Regards, Alexander (In reply to Emil Velikov from comment #2) > I believe that this issue is not that specific to mesa and/or the build > system. > > I've had similar experience with piglit (which uses cmake). The workaround I > used was to use the shortest path possible for the repo and install location > (iirc I used e:\p\ and e:\i\ respectively) Unlike CMake, SCons uses option files with MSVC, so this doesn't affect MSVC. It can pass as many options as theres free space in the hard drive. It's just SCons + MinGW on Windows. > The mesa MSVC builds have been running fine but I'm wondering if we > cannot wire up the mingw/mingw-w64 ones ? First need to fix this bug before it's worthwhile. (In reply to sav_ix from comment #0) > While looking for solution, found in SCons wiki: > "MingW had some problems during the link phase of the build process. It > turned out our link lines were in excess of 10000 characters, and this was > causing some major grief with python calling spawn()..." > (details at https://bitbucket.org/scons/scons/wiki/LongCmdLinesOnWin32 ). We probably need something like this. It's not the first time SCons usage of CRT exec causes problems. We also had random build failures with SCons on Windows with parallel builds because the CRT is not thread safe. It would be great if SCons migrated to subprocess. I tried to update mesa/scons/fixes.py with the hack from https://bitbucket.org/scons/scons/wiki/LongCmdLinesOnWin32 without success. The snippet from https://bitbucket.org/scons/scons/wiki/LongCmdLinesOnWin32 is missing the defition of `escape` I also tried using subprocess but it fails. Honestly, the only solution IMO is to fix upstream scons/src/engine/SCons/Platform/win32.py file... -- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/913. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.