appveyor mingw64 build fails #6248
Comments
|
@Lord-Nightmare seemed to have a similar issue that he solved by rolling back the MinGW GNU make package in his MSYS2 environment. |
|
Thanks for the tip, downgrading make from 4.3-1 to 4.2.1-1 seems to have done the trick. I will file a bug with msys2. |
|
The error I ran into was "Archiving libformats.a... Hypothesis: I'm guessing it is path length dependent; my mame compile base directory is in "c:\root\mame\mame" so depending on the exact length of the commands plus path (maybe at a 256 byte boundary?) a space is getting dropped, but only for make commands which happen to have the exact specific length/offset-of-space-characters to trigger it? I'm not sure this is the reason, but it could be the cause... It needs further testing, which I currently can't do as I'm going to be upgrading to a new system within the next few days. |
|
Msys2 developer has referred to the make release notes: WARNING: Backward-incompatibility! Previously appending using '+=' to an empty variable would result in a value starting with a space. Now the initial space is only added if the variable already contains some value. Similarly, appending an empty string does not add a trailing space. |
|
A quick hack that fixes the build with make 4.3, |
|
Thanks, your fix worked! The non-hacky way is to edit 3rdparty/genie/src/actions/make/make_cpp.lua and then run Would you like to submit the PR upstream, or should I? |
|
Here is the make_cpp.lua patch: diff --git a/3rdparty/genie/src/actions/make/make_cpp.lua b/3rdparty/genie/src/actions/make/make_cpp.lua
index a4e92521bd..880d9d35bf 100644
--- a/3rdparty/genie/src/actions/make/make_cpp.lua
+++ b/3rdparty/genie/src/actions/make/make_cpp.lua
@@ -73,8 +73,8 @@
if (prj.kind == "StaticLib" and prj.options.ArchiveSplit) then
_p('define max_args')
_p('\t$(eval _args:=)')
- _p('\t$(foreach obj,$3,$(eval _args+=$(obj))$(if $(word $2,$(_args)),$1$(_args)$(EOL)$(eval _args:=)))')
- _p('\t$(if $(_args),$1$(_args))')
+ _p('\t$(foreach obj,$3,$(eval _args+=$(obj))$(if $(word $2,$(_args)),$1 $(_args)$(EOL)$(eval _args:=)))')
+ _p('\t$(if $(_args),$1 $(_args))')
_p('endef')
_p('')
_p('define EOL') |
|
If you are familiar with genie - please submit the PR, I know absolutely nothing about genie. |
|
does it work when you arent using the bash shell?
…On 03/02/2020 19:15, Julian Sikorski wrote:
Thanks, your fix worked! The non-hacky way is to edit
3rdparty/genie/src/actions/make/make_cpp.lua and then run
|$ genie embed |
Would you like to submit the PR upstream, or should I?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#6248?email_source=notifications&email_token=ACGVYYTT6O6WZV7TPW4H3G3RBBUMDA5CNFSM4KOTXXY2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEKVBNYY#issuecomment-581572323>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ACGVYYV2HZ5HLN4FTPCDDHLRBBUMDANCNFSM4KOTXXYQ>.
|
|
I just tested with win32env.bat and it worked. win32env.bat appears to be using make-4.1, which also explains why it was not affected by the original issue. |
This was referenced Feb 4, 2020
10 tasks
AluisioASG
added a commit
to AluisioASG/nixpkgs
that referenced
this issue
Oct 28, 2020
Builds currently fail with `ar` trying to operate on what are clearly two paths concatenated together. It stems from a backward-incompatible change in Make: > Previously appending using '+=' to an empty variable would result in > a value starting with a space. Now the initial space is only added > if the variable already contains some value. Similarly, appending an > empty string does not add a trailing space. This issue was first reported on the MAME repository proper (mamedev/mame#6248), and affects libretro's 2016 snapshot as well. A fix that is reported to work with previous versions of Make was upstreamed to: - GENie, the build system: bkaradzic/GENie#493 - MAME: mamedev/mame#6262 - libretro: libretro/mame2016-libretro#47 The fetched patch comes from the last of these.
AluisioASG
added a commit
to AluisioASG/nixpkgs
that referenced
this issue
Oct 30, 2020
Builds currently fail with `ar` trying to operate on what are clearly two paths concatenated together. It stems from a backward-incompatible change in Make: > Previously appending using '+=' to an empty variable would result in > a value starting with a space. Now the initial space is only added > if the variable already contains some value. Similarly, appending an > empty string does not add a trailing space. This issue was first reported on the MAME repository proper (mamedev/mame#6248), and affects libretro's 2016 snapshot as well. A fix that is reported to work with previous versions of Make was upstreamed to: - GENie, the build system: bkaradzic/GENie#493 - MAME: mamedev/mame#6262 - libretro: libretro/mame2016-libretro#47 The fetched patch comes from the last of these. (cherry picked from commit 8880179)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Appveyor MINGW build has started failing 9 days ago:
https://ci.appveyor.com/project/startaq/mame/builds/30306506
I was able to reproduce it locally when using bash shell:
Strangely enough build works in cmd shell started with win32env.bat.
It appears to me that there is a space missing between libemu.a and the path leading to addrmap.o. Any ideas what might have swallowed it? No commit between be36db0 and eb33990 touches anything global so I am guessing pacman update is to blame.
The text was updated successfully, but these errors were encountered: