[yocto] meta-mingw: unable to run executables on Windows

[Samuli Piippo]

Hi,

I've just upgraded poky and meta-mingw layers from sumo to thud and as a
result a lot of the executables in the toolchain no longer run correctly on
Windows.

I've built meta-toolchain for SDKMACHINE=x86_64-mingw32. From that, gcc/g++
work fine on Windows 10, but ar, as, objdumb, and others hang for ~30
seconds and exit without any output.

Has anyone else seen this?

[Burton, Ross]

I've just upgraded poky and meta-mingw layers from sumo to thud and as a result a lot of the executables in the toolchain no longer run correctly on Windows.
I've built meta-toolchain for SDKMACHINE=x86_64-mingw32. From that, gcc/g++ work fine on Windows 10, but ar, as, objdumb, and others hang for ~30 seconds and exit without any output.
Has anyone else seen this?

I suspect we need to find a maintainer who actually uses meta-mingw
and can actually test it. Would you be willing to bisect thud to sumo
to identify where it breaks?

Ross
--

[Samuli Piippo]

Post by Burton, Ross

I've just upgraded poky and meta-mingw layers from sumo to thud and as a result a lot of the executables in the toolchain no longer run correctly on Windows.
I've built meta-toolchain for SDKMACHINE=x86_64-mingw32. From that, gcc/g++ work fine on Windows 10, but ar, as, objdumb, and others hang for ~30 seconds and exit without any output.
Has anyone else seen this?

I suspect we need to find a maintainer who actually uses meta-mingw
and can actually test it. Would you be willing to bisect thud to sumo
to identify where it breaks?

I can try to setup some kind of automatic bisect run script to test this.
--

[Mark Hatle]

Hi,
I've just upgraded poky and meta-mingw layers from sumo to thud and as a result
a lot of the executables in the toolchain no longer run correctly on Windows.

Which version of windows?

I've built meta-toolchain for SDKMACHINE=x86_64-mingw32. From that, gcc/g++ work
fine on Windows 10, but ar, as, objdumb, and others hang for ~30 seconds and
exit without any output.
Has anyone else seen this?

I've run a toolchain made on mingw after sumo, but before thud's release. I'll
see if I can find a VM and give it a try later today.

--Mark
--

[Mark Hatle]

Post by Mark Hatle

Hi,
I've just upgraded poky and meta-mingw layers from sumo to thud and as a result
a lot of the executables in the toolchain no longer run correctly on Windows.

Which version of windows?

I've built meta-toolchain for SDKMACHINE=x86_64-mingw32. From that, gcc/g++ work
fine on Windows 10, but ar, as, objdumb, and others hang for ~30 seconds and
exit without any output.
Has anyone else seen this?

I've run a toolchain made on mingw after sumo, but before thud's release. I'll
see if I can find a VM and give it a try later today.

I'm running on Windows 7 for my testing (ya, I know old.. but it's what I got.)

Can you try adding the following to your conf/local.conf: GCCPIE_mingw32 = ""

I found that the SDK was not working properly here as well, but only binutils.
The above seems to fix the issue. (You do have to rebuild your SDK.)

Post by Mark Hatle
--Mark

--

[Joshua Watt]

Post by Mark Hatle

Post by Mark Hatle

Hi,
I've just upgraded poky and meta-mingw layers from sumo to thud and as a result
a lot of the executables in the toolchain no longer run correctly on Windows.

Which version of windows?

I've built meta-toolchain for SDKMACHINE=x86_64-mingw32. From that, gcc/g++ work
fine on Windows 10, but ar, as, objdumb, and others hang for ~30 seconds and
exit without any output.
Has anyone else seen this?

I've run a toolchain made on mingw after sumo, but before thud's release. I'll
see if I can find a VM and give it a try later today.

I'm running on Windows 7 for my testing (ya, I know old.. but it's what I got.)
Can you try adding the following to your conf/local.conf: GCCPIE_mingw32 = ""
I found that the SDK was not working properly here as well, but only binutils.
The above seems to fix the issue. (You do have to rebuild your SDK.)

I also saw this issue on Windows 7, and your described fix corrected
it (Thanks!). On the plus side, the automated SDK testing that I'm
working on discovered it as well (e.g. the tests failed because of
it), which means that the tests are working and should help prevent
issues like this in the future once I get it merged.

Post by Mark Hatle

Post by Mark Hatle
--Mark

--
_______________________________________________
yocto mailing list
https://lists.yoctoproject.org/listinfo/yocto

--

[Khem Raj]

Post by Joshua Watt

Post by Mark Hatle

Post by Mark Hatle

Hi,
I've just upgraded poky and meta-mingw layers from sumo to thud and as a result
a lot of the executables in the toolchain no longer run correctly on Windows.

Which version of windows?

I've built meta-toolchain for SDKMACHINE=x86_64-mingw32. From that, gcc/g++ work
fine on Windows 10, but ar, as, objdumb, and others hang for ~30 seconds and
exit without any output.
Has anyone else seen this?

I've run a toolchain made on mingw after sumo, but before thud's release. I'll
see if I can find a VM and give it a try later today.

I'm running on Windows 7 for my testing (ya, I know old.. but it's what I got.)
Can you try adding the following to your conf/local.conf: GCCPIE_mingw32 = ""

this will be effective just for SDK and native versions I hope, but in
cases if we
have this override also applicable for target then this fix is not
correct. We have
to keep using it for target builds.

Post by Joshua Watt

Post by Mark Hatle
I found that the SDK was not working properly here as well, but only binutils.
The above seems to fix the issue. (You do have to rebuild your SDK.)

I also saw this issue on Windows 7, and your described fix corrected
it (Thanks!). On the plus side, the automated SDK testing that I'm
working on discovered it as well (e.g. the tests failed because of
it), which means that the tests are working and should help prevent
issues like this in the future once I get it merged.

Post by Mark Hatle

Post by Mark Hatle
--Mark

--
_______________________________________________
yocto mailing list
https://lists.yoctoproject.org/listinfo/yocto

--
_______________________________________________
yocto mailing list
https://lists.yoctoproject.org/listinfo/yocto

--

[Samuli Piippo]

Post by Khem Raj

Post by Joshua Watt

Post by Mark Hatle

Post by Mark Hatle

Hi,
I've just upgraded poky and meta-mingw layers from sumo to thud and as a result
a lot of the executables in the toolchain no longer run correctly on Windows.

Which version of windows?

I've built meta-toolchain for SDKMACHINE=x86_64-mingw32. From that, gcc/g++ work
fine on Windows 10, but ar, as, objdumb, and others hang for ~30 seconds and
exit without any output.
Has anyone else seen this?

I've run a toolchain made on mingw after sumo, but before thud's release. I'll
see if I can find a VM and give it a try later today.

I'm running on Windows 7 for my testing (ya, I know old.. but it's what I got.)
Can you try adding the following to your conf/local.conf: GCCPIE_mingw32 = ""

this will be effective just for SDK and native versions I hope, but in
cases if we
have this override also applicable for target then this fix is not
correct. We have
to keep using it for target builds.

Post by Joshua Watt

Post by Mark Hatle
I found that the SDK was not working properly here as well, but only binutils.
The above seems to fix the issue. (You do have to rebuild your SDK.)

I also saw this issue on Windows 7, and your described fix corrected
it (Thanks!). On the plus side, the automated SDK testing that I'm
working on discovered it as well (e.g. the tests failed because of
it), which means that the tests are working and should help prevent
issues like this in the future once I get it merged.

bisect finished last night and the winner was: commit
491082c56ce34f3fd644f8d4457ccd52af951087
poky.conf: Enable security flags+pie by defaultEnable security
flags+pie by default

Adding GCCPIE_mingw32 = "" fixes this also for Windows 10
--

[Burton, Ross]

Good work!

Can we have a patch from someone please?

Ross

Post by Khem Raj

Post by Joshua Watt

Post by Mark Hatle

Post by Mark Hatle

Post by Samuli Piippo
Hi,
I've just upgraded poky and meta-mingw layers from sumo to thud

and as a result

Post by Khem Raj

Post by Joshua Watt

Post by Mark Hatle

Post by Mark Hatle

Post by Samuli Piippo
a lot of the executables in the toolchain no longer run correctly

on Windows.

Post by Khem Raj

Post by Joshua Watt

Post by Mark Hatle

Post by Mark Hatle
Which version of windows?

Post by Samuli Piippo
I've built meta-toolchain for SDKMACHINE=x86_64-mingw32. From

that, gcc/g++ work

Post by Khem Raj

Post by Joshua Watt

Post by Mark Hatle

Post by Mark Hatle

Post by Samuli Piippo
fine on Windows 10, but ar, as, objdumb, and others hang for ~30

seconds and

Post by Khem Raj

Post by Joshua Watt

Post by Mark Hatle

Post by Mark Hatle

Post by Samuli Piippo
exit without any output.
Has anyone else seen this?

I've run a toolchain made on mingw after sumo, but before thud's

release. I'll

Post by Khem Raj

Post by Joshua Watt

Post by Mark Hatle

Post by Mark Hatle
see if I can find a VM and give it a try later today.

I'm running on Windows 7 for my testing (ya, I know old.. but it's

what I got.)
GCCPIE_mingw32 = ""

Post by Khem Raj
this will be effective just for SDK and native versions I hope, but in
cases if we
have this override also applicable for target then this fix is not
correct. We have
to keep using it for target builds.

Post by Joshua Watt

Post by Mark Hatle
I found that the SDK was not working properly here as well, but only

binutils.

Post by Khem Raj

Post by Joshua Watt

Post by Mark Hatle
The above seems to fix the issue. (You do have to rebuild your SDK.)

I also saw this issue on Windows 7, and your described fix corrected
it (Thanks!). On the plus side, the automated SDK testing that I'm
working on discovered it as well (e.g. the tests failed because of
it), which means that the tests are working and should help prevent
issues like this in the future once I get it merged.

bisect finished last night and the winner was: commit
491082c56ce34f3fd644f8d4457ccd52af951087
poky.conf: Enable security flags+pie by defaultEnable security
flags+pie by default
Adding GCCPIE_mingw32 = "" fixes this also for Windows 10
--
_______________________________________________
yocto mailing list
https://lists.yoctoproject.org/listinfo/yocto

[Samuli Piippo]

patch sent.

Post by Burton, Ross
Good work!
Can we have a patch from someone please?
Ross

Post by Samuli Piippo

Post by Khem Raj

Post by Joshua Watt

Post by Mark Hatle

Post by Mark Hatle

Hi,
I've just upgraded poky and meta-mingw layers from sumo to thud and as a result
a lot of the executables in the toolchain no longer run correctly on Windows.

Which version of windows?

I've built meta-toolchain for SDKMACHINE=x86_64-mingw32. From that, gcc/g++ work
fine on Windows 10, but ar, as, objdumb, and others hang for ~30 seconds and
exit without any output.
Has anyone else seen this?

I've run a toolchain made on mingw after sumo, but before thud's release. I'll
see if I can find a VM and give it a try later today.

I'm running on Windows 7 for my testing (ya, I know old.. but it's what I got.)
Can you try adding the following to your conf/local.conf: GCCPIE_mingw32 = ""

this will be effective just for SDK and native versions I hope, but in
cases if we
have this override also applicable for target then this fix is not
correct. We have
to keep using it for target builds.

Post by Joshua Watt

Post by Mark Hatle
I found that the SDK was not working properly here as well, but only binutils.
The above seems to fix the issue. (You do have to rebuild your SDK.)

I also saw this issue on Windows 7, and your described fix corrected
it (Thanks!). On the plus side, the automated SDK testing that I'm
working on discovered it as well (e.g. the tests failed because of
it), which means that the tests are working and should help prevent
issues like this in the future once I get it merged.

bisect finished last night and the winner was: commit
491082c56ce34f3fd644f8d4457ccd52af951087
poky.conf: Enable security flags+pie by defaultEnable security
flags+pie by default
Adding GCCPIE_mingw32 = "" fixes this also for Windows 10
--
_______________________________________________
yocto mailing list
https://lists.yoctoproject.org/listinfo/yocto

--

[Burton, Ross]

Didn't see it arrive, maybe it's lost in moderation? What list did
you post it to?

Ross

Post by Samuli Piippo
patch sent.

Post by Burton, Ross
Good work!
Can we have a patch from someone please?
Ross

Post by Samuli Piippo

Post by Khem Raj

Post by Joshua Watt

Post by Mark Hatle

Post by Mark Hatle

Hi,
I've just upgraded poky and meta-mingw layers from sumo to thud and as a result
a lot of the executables in the toolchain no longer run correctly on Windows.

Which version of windows?

I've built meta-toolchain for SDKMACHINE=x86_64-mingw32. From that, gcc/g++ work
fine on Windows 10, but ar, as, objdumb, and others hang for ~30 seconds and
exit without any output.
Has anyone else seen this?

I've run a toolchain made on mingw after sumo, but before thud's release. I'll
see if I can find a VM and give it a try later today.

I'm running on Windows 7 for my testing (ya, I know old.. but it's what I got.)
Can you try adding the following to your conf/local.conf: GCCPIE_mingw32 = ""

this will be effective just for SDK and native versions I hope, but in
cases if we
have this override also applicable for target then this fix is not
correct. We have
to keep using it for target builds.

Post by Joshua Watt

Post by Mark Hatle
I found that the SDK was not working properly here as well, but only binutils.
The above seems to fix the issue. (You do have to rebuild your SDK.)

I also saw this issue on Windows 7, and your described fix corrected
it (Thanks!). On the plus side, the automated SDK testing that I'm
working on discovered it as well (e.g. the tests failed because of
it), which means that the tests are working and should help prevent
issues like this in the future once I get it merged.

bisect finished last night and the winner was: commit
491082c56ce34f3fd644f8d4457ccd52af951087
poky.conf: Enable security flags+pie by defaultEnable security
flags+pie by default
Adding GCCPIE_mingw32 = "" fixes this also for Windows 10
--
_______________________________________________
yocto mailing list
https://lists.yoctoproject.org/listinfo/yocto

--

[Mark Hatle]

Post by Khem Raj

Post by Joshua Watt

Post by Mark Hatle

Post by Mark Hatle

Hi,
I've just upgraded poky and meta-mingw layers from sumo to thud and as a result
a lot of the executables in the toolchain no longer run correctly on Windows.

Which version of windows?

I've built meta-toolchain for SDKMACHINE=x86_64-mingw32. From that, gcc/g++ work
fine on Windows 10, but ar, as, objdumb, and others hang for ~30 seconds and
exit without any output.
Has anyone else seen this?

I've run a toolchain made on mingw after sumo, but before thud's release. I'll
see if I can find a VM and give it a try later today.

I'm running on Windows 7 for my testing (ya, I know old.. but it's what I got.)
Can you try adding the following to your conf/local.conf: GCCPIE_mingw32 = ""

this will be effective just for SDK and native versions I hope, but in
cases if we
have this override also applicable for target then this fix is not
correct. We have
to keep using it for target builds.

The mingw32 override is only present when building -nativesdk- mingw32 software.
-Not- cross candian and similar.

--Mark

Post by Khem Raj

Post by Joshua Watt

Post by Mark Hatle
I found that the SDK was not working properly here as well, but only binutils.
The above seems to fix the issue. (You do have to rebuild your SDK.)

I also saw this issue on Windows 7, and your described fix corrected
it (Thanks!). On the plus side, the automated SDK testing that I'm
working on discovered it as well (e.g. the tests failed because of
it), which means that the tests are working and should help prevent
issues like this in the future once I get it merged.

Post by Mark Hatle

Post by Mark Hatle
--Mark

--
_______________________________________________
yocto mailing list
https://lists.yoctoproject.org/listinfo/yocto

--
_______________________________________________
yocto mailing list
https://lists.yoctoproject.org/listinfo/yocto

--

[Khem Raj]

Ok, thanks.

Post by Mark Hatle

Post by Khem Raj

Post by Joshua Watt

Post by Mark Hatle

Post by Mark Hatle

Hi,
I've just upgraded poky and meta-mingw layers from sumo to thud and as a result
a lot of the executables in the toolchain no longer run correctly on Windows.

Which version of windows?

I've built meta-toolchain for SDKMACHINE=x86_64-mingw32. From that, gcc/g++ work
fine on Windows 10, but ar, as, objdumb, and others hang for ~30 seconds and
exit without any output.
Has anyone else seen this?

I've run a toolchain made on mingw after sumo, but before thud's release. I'll
see if I can find a VM and give it a try later today.

I'm running on Windows 7 for my testing (ya, I know old.. but it's what I got.)
Can you try adding the following to your conf/local.conf: GCCPIE_mingw32 = ""

this will be effective just for SDK and native versions I hope, but in
cases if we
have this override also applicable for target then this fix is not
correct. We have
to keep using it for target builds.

The mingw32 override is only present when building -nativesdk- mingw32 software.
-Not- cross candian and similar.
--Mark

Post by Khem Raj

Post by Joshua Watt

Post by Mark Hatle
I found that the SDK was not working properly here as well, but only binutils.
The above seems to fix the issue. (You do have to rebuild your SDK.)

I also saw this issue on Windows 7, and your described fix corrected
it (Thanks!). On the plus side, the automated SDK testing that I'm
working on discovered it as well (e.g. the tests failed because of
it), which means that the tests are working and should help prevent
issues like this in the future once I get it merged.

Post by Mark Hatle

Post by Mark Hatle
--Mark

--
_______________________________________________
yocto mailing list
https://lists.yoctoproject.org/listinfo/yocto

--
_______________________________________________
yocto mailing list
https://lists.yoctoproject.org/listinfo/yocto

--