Continuation of bug 5256. We should eventually upgrade to GCC 4.9.X or later.
Created attachment 598 [details] CTC patch to fix (some) GCC 4.9 problems
libgcc_s is getting pulled in a lot more on Windows builds. Unfortunately PE COFF is horrible so the magic that is being used on ELF system to keep libgcc_s usage sane cannot be used there. In our current gcc libgcc_s is only used if you explicitly specify -shared-libgcc. In the new gcc you'll get libgcc_s by default for DLL:s, but not exe:s. It looks like it will be libgcc_s by default for both soon though. We need to update our Makefile:s to deal with this. Right now it's opensc and pulseaudio that's affected.
(In reply to comment #2) > libgcc_s is getting pulled in a lot more on Windows builds. Unfortunately PE > COFF is horrible so the magic that is being used on ELF system to keep libgcc_s > usage sane cannot be used there. > > In our current gcc libgcc_s is only used if you explicitly specify > -shared-libgcc. In the new gcc you'll get libgcc_s by default for DLL:s, but > not exe:s. It looks like it will be libgcc_s by default for both soon though. > > We need to update our Makefile:s to deal with this. Right now it's opensc and > pulseaudio that's affected. r30453.
ld64 upgraded and packaged separately in r30466.
gcc upgraded to 5.1.0 in r30472.
All done. Tester should verify that we are using 5.1.0 in our build environment, and that our binaries work on every of our targets. Testing the client and its local redirections is sufficient.
unfsd seems broken on Windows: > $ tl-mount-localdrives > mount.nfs: access denied by server while mounting localhost:@otp:[...]/c/Temp This is build 4824. Happens on both Windows 7 and 8 - I haven't tested anything older. Dropping in a unfsd binary from 4.4.0 results in everything working fine.
There is some file handle lookup issue. The first MNT request succeeds, but the following FSINFO returns NSF3ERR_STALE. The kernel then retries the MNT and gets ERR_ACCESS because the nonce is now invalid.
Urgh. It seems the packed attribute is broken for Windows targets on gcc 4.7+. Upstream bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52991 Although it might have worked without this bug, it isn't entirely clear it's safe anyway since apparently gcc and visual studio packs things differently. So I still suggest my general principle of staying clear of packed and type punning.
unfsd improved in r30605. Also need to revert the default in gcc.
gcc default changed in r30607. Probably need to retest the Windows binaries a bit after this.
(In reply to comment #6) > All done. Tester should verify that we are using 5.1.0 in our build > environment, and that our binaries work on every of our targets. Testing the > client and its local redirections is sufficient. Apart from the now-fixed unfsd bug from comment #7, I found no flaws testing all the clients, and the fix for comment #7 is working just fine.
(In reply to comment #10) > unfsd improved in r30605. Also need to revert the default in gcc. This commit or the gcc upgrade introduces a regression. unfsd fails to write files bigger than ~175Mb. The bug is provoked by using windows thinlinc client and creating a file in thindrives using: dd if=/dev/zero of=./data.raw bs=1M count=1024. unfsd reports hudnreds lines of following error to tlclient.log file: 2015-10-07T11:03:30: unfsd[E]: Seeking for offset -1835008 failed when writing. 2015-10-07T11:03:30: unfsd[E]: Seeking for offset -1572864 failed when writing. 2015-10-07T11:03:30: unfsd[E]: Seeking for offset -1310720 failed when writing. 2015-10-07T11:03:30: unfsd[E]: Seeking for offset -1048576 failed when writing. 2015-10-07T11:03:30: unfsd[E]: Seeking for offset -786432 failed when writing. 2015-10-07T11:03:30: unfsd[E]: Seeking for offset -524288 failed when writing. 2015-10-07T11:03:30: unfsd[E]: Seeking for offset -262144 failed when writing. 2015-10-07T11:03:30: unfsd[E]: Seeking for offset -8388608 failed when writing. 2015-10-07T11:03:30: unfsd[E]: Seeking for offset -8126464 failed when writing.
