On Sun, 18 Sep 2022, Sergei Trofimovich wrote:
Before the change massively parallel builds failed when Makefile
attempted to build both lib64/libd3dx9_38.a and lib32/libd3dx9_38.a:
x86_64-w64-mingw32-dlltool --as-flags=--64 -m i386:x86-64 ... \
--output-lib lib64/libd3dx9_38.a \
--temp-prefix $(basename lib64/libd3dx9_38.a .a) ...
...
x86_64-w64-mingw32-dlltool --as-flags=--32 -m i386 ... \
--output-lib lib32/libd3dx9_38.a \
--temp-prefix $(basename lib32/libd3dx9_38.a .a) ...
x86_64-w64-mingw32-dlltool: bfd_open failed reopen stub file: \
libd3dx9_38s00271.o: No such file or directory
make[3]: *** [Makefile:77947: lib32/libd3dx9_38.a] Error 1 shuffle=1662967885
make[3]: *** Waiting for unfinished jobs....
Thanks for the patch, and I'm sorry you've run into this issue. However,
I'm pretty sure that this issue already is fixed in git master (where
you've made your patch).
I assume you've run into this issue in the tagged v10.0.0 release, then
analyzed the issue and fixed it there, and gone ahead and adapted the fix
on top of git master, without retesting that the issue still was present
on git master? (The fact that it is fixed is very subtle though.)
This issue was fixed in 953bcd32ae470c4647e94de8548dda5a8f07d82d in git
master. Before the fix, the commands looked like what you quoted above,
calling dlltool with "--temp-prefix $(basename lib64/libd3dx9_38.a .a)".
However, after the fix, the make output prints them as being called with
"--temp-prefix lib64/libd3dx9_38" (the difference between $(basename) and
$$(basename) in that fix commit is very subtle, but should fix the issue).
Can you retest your issue on latest git master?
BTW, we generally don't include the updates to Makefile.in in the patches
posted to the list.
// Martin
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
