from:"Sven Kretzschmar"

Re: [Mingw-w64-public] Challenges with using ucrtbase option for cross compiling...

2017-11-29 Thread Sven Kretzschmar


After the recent patches fixed a lot of the problems with building & running 
the mingw64 cross gnu toolchain with
"--with-default-msvcrt=ucrtbase" option, I have run some further tests 
concerning the seemingly broken pipe / fd handling probs:

Status:
-
- Cross-Toolchain built with standard binary cygwin x86_64-w64-mingw32 
cross-toolchain packages:
=> OK.
- Cross-Toolchain built myself from source with cygwin environment using 
x86_64-w64-mingw32 cross-toolchain sources 
  _without_ "--with-default-msvcrt=ucrtbase" option: 
=> OK.

- Cross-Toolchain built myself from source with cygwin environment using 
x86_64-w64-mingw32 cross-toolchain sources 
  _with_ "--with-default-msvcrt=ucrtbase" option:
=> NOT OK !
Problems: Broken in/output handling, broken pipes, errors opening a named pipe, 
maybe broken crt initialization/handling of standard file descriptors:
- mingwcrt "make check-TESTS" showed undefined references : _setjmp , __pioinfo 
& wprintf (last one should be easy to fix)
- libuv "make check" showed broken outputs & all tests failed with messed up 
output.
- Julia "make testall" showed a broken pipe error in the first test & stopped.

I don't know much in detail about the crt initialization & handling of 
(standard) file descriptors, but the broken pipes & messed up outputs seem to
point in this direction. I have no idea where exactly to look to fix this 
problem.

==> Maybe some of the mingw64 developers have some ideas about these problems - 
it happens only in the ucrtbase version of the cross toolchain. ?

I have attached all outputs from the tests with and without the "ucrtbase" 
option to this post & hope this might help in further problem analysis & 
potential
fixes.

Thanks & Cheers
- Sven

P.S.: I used the current mingw64 master branch

-Original Message-
From: Sven Kretzschmar [mailto:sven.kretzsch...@gmx.de] 
Sent: 26 November 2017 18:07
To: 'mingw-w64-public@lists.sourceforge.net' 
<mingw-w64-public@lists.sourceforge.net>
Subject: RE: [Mingw-w64-public] [PATCH] ucrtbase: Don't include a import 
library alias "tzset"


Hi Martin,

Thanks for your patch. It fixed the problem.

When running the compiled Julia, I now get an error in its initialization when 
it tries to open a named pipe for stderr - fd 2 (it uses libuv).
Also , it immediately finishes after start & messes up stdout in the Cygwin 
shell (no more stdin echo to stdout)...
If I start it via a native Windows cmd shell, it (Julia.exe) seems to behave 
normally with non-messed up stdout...
As soon as stdin/out/err is involved, it seems to behave erratically.

I will check this further & report back here when I found a more specific 
reason / error description.

Thanks :)
- Sven

-Original Message-
From: Martin Storsjö [mailto:mar...@martin.st] 
Sent: 25 November 2017 21:13
To: mingw-w64-public@lists.sourceforge.net
Subject: [Mingw-w64-public] [PATCH] ucrtbase: Don't include a import library 
alias "tzset"

This was missed in 483ddaaf1b09590756ff8c59bc2db7501d7364f9.

Signed-off-by: Martin Storsjö <mar...@martin.st>
---
 mingw-w64-crt/def-include/msvcrt-common.def.in | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mingw-w64-crt/def-include/msvcrt-common.def.in 
b/mingw-w64-crt/def-include/msvcrt-common.def.in
index 9fb8dc2..c0418fc 100644
--- a/mingw-w64-crt/def-include/msvcrt-common.def.in
+++ b/mingw-w64-crt/def-include/msvcrt-common.def.in
@@ -92,7 +92,9 @@ ADD_UNDERSCORE(strupr)
 ADD_UNDERSCORE(swab)
 ADD_UNDERSCORE(tell)
 ADD_UNDERSCORE(tempnam)
+#ifndef UCRTBASE
 ADD_UNDERSCORE(tzset)
+#endif
 ADD_UNDERSCORE(umask)
 ADD_UNDERSCORE(ungetch)
 ADD_UNDERSCORE(unlink)
-- 
2.7.4


configure options used for gcc 6.4.0:
../../src/gcc/configure --prefix=/CROSS64 --build=x86_64-pc-cygwin 
--host=x86_64-pc-cygwin --target=x86_64-w64-mingw32 --with-sysroot=/CROSS64 
--with-build-sysroot=/CROSS64 --enable-languages=c,c++,fortran,lto 
--disable-multilib --disable-win32-registry --enable-fully-dynamic-string 
--enable-graphite --enable-libgomp --enable-libquadmath 
--enable-libquadmath-support --enable-libssp 
--enable-version-specific-runtime-libs --with-dwarf2 --with-gnu-ld 
--with-gnu-as --with-tune=generic --with-system-zlib --enable-threads=posix 
--disable-bootstrap --enable-lto --enable-checking=release --disable-rpath 
--disable-werror --without-libiconv-prefix --without-libintl-prefix 
--disable-symvers --enable-wchar_t

==
OUTPUT with mingw64 toochain built _with_ "--with-default-msvcrt=ucrtbase" 
option:
==
configure options used for mingw64-headers:
../../src/mingw-w64/mingw-w64-headers/configure 
--prefix=/CROSS64/x86_64-w64-mingw32 --build=x86_64-pc-cygwin 
--host

Re: [Mingw-w64-public] [PATCH 2/2] Use public _acmdln and _wcmdln declarations in crt and get rid of no loner needed ucrtbase compat hack.

2017-11-27 Thread Sven Kretzschmar

It seems that this patch somehow broke cross-compiling the gnu toolchain when 
_not_ using the "--with-default-msvcrt=ucrtbase" option.

I am getting the following errors during "make" in gcc subdir (final build step 
for building cross-compiler from Cygwin to mingw64 x86_64):
configure:3713: checking for C compiler default output file name
configure:3735: /home/sven/buildtmp/build/gcc/./gcc/xgcc 
-B/home/sven/buildtmp/build/gcc/./gcc/ -L/CROSS64/x86_64-w64-mingw32/lib 
-L/CROSS64/mingw/lib -isystem /CROSS64/x86_64-w64-mingw32/include -isystem 
/CROSS64/mingw/include -B/CROSS64/x86_64-w64-mingw32/bin/ 
-B/CROSS64/x86_64-w64-mingw32/lib/ -isystem /CROSS64/x86_64-w64-mingw32/include 
-isystem /CROSS64/x86_64-w64-mingw32/sys-include --sysroot=/CROSS64   -g -O2   
conftest.c  >&5
/CROSS64/x86_64-w64-mingw32/lib/crt2.o: In function `__tmainCRTStartup':
/home/sven/buildtmp/build/mingw-crt/../../src/mingw-w64/mingw-w64-crt/crt/crtexe.c:301:
 undefined reference to `__p__acmdln'
collect2: error: ld returned 1 exit status
==>(from config.log generated while building libgomp for gcc)

Also I get the following error while executing a "make check" when building  
winpthreads (../src/mingw-w64/mingw-w64-libraries/winpthreads/):
make[2]: Entering directory '/home/sven/buildtmp/build/winpthreads/tests'
/bin/sh ../libtool  --tag=CC   --mode=link x86_64-w64-mingw32-gcc  -g -O2 
-L../fakelib -L.. -lwinpthread -static  -o t_clock_getres t_clock_getres.o
libtool: link: x86_64-w64-mingw32-gcc -g -O2 -o t_clock_getres t_clock_getres.o 
 -L../fakelib -L.. /home/sven/buildtmp/build/winpthreads/.libs/libwinpthread.a 
-L./fakelib
/CROSS64/lib/gcc/x86_64-w64-mingw32/6.4.0/../../../../x86_64-w64-mingw32/lib/../lib/crt2.o:
 In function `__tmainCRTStartup':
/home/sven/buildtmp/build/mingw-crt/../../src/mingw-w64/mingw-w64-crt/crt/crtexe.c:301:
 undefined reference to `__p__acmdln'
collect2: error: ld returned 1 exit status

Question:
--
Do you have an idea how to fix this ?
Should I just revoke the corresponding change/patch ? :
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/fa33563b8f3f128d62257f1bc24bae9f04a5e14a/

Thanks
- Sven

-Original Message-
From: Martin Storsjö [mailto:mar...@martin.st] 
Sent: 24 November 2017 20:59
To: mingw-w64-public 
Subject: Re: [Mingw-w64-public] [PATCH 2/2] Use public _acmdln and _wcmdln 
declarations in crt and get rid of no loner needed ucrtbase compat hack.

On Fri, 24 Nov 2017, Jacek Caban wrote:

> Signed-off-by: Jacek Caban 
> ---
> mingw-w64-crt/crt/ucrtbase_compat.c |  8 
> mingw-w64-crt/include/internal.h| 12 
> 2 files changed, 20 deletions(-)

Nice, thanks!

Signed-off-by: Martin Storsjö 

(Fee free to add the S-o-b to all the other ones as well, I forgot to add it to 
the replies.)

// Martin
--
Check out the vibrant tech community on one of the world's most engaging tech 
sites, Slashdot.org! http://sdm.link/slashdot 
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] ucrtbase: Don't include a import library alias "tzset"

2017-11-26 Thread Sven Kretzschmar


Hi Martin,

Thanks for your patch. It fixed the problem.

When running the compiled Julia, I now get an error in its initialization when 
it tries to open a named pipe for stderr - fd 2 (it uses libuv).
Also , it immediately finishes after start & messes up stdout in the Cygwin 
shell (no more stdin echo to stdout)...
If I start it via a native Windows cmd shell, it (Julia.exe) seems to behave 
normally with non-messed up stdout...
As soon as stdin/out/err is involved, it seems to behave erratically.

I will check this further & report back here when I found a more specific 
reason / error description.

Thanks :)
- Sven

-Original Message-
From: Martin Storsjö [mailto:mar...@martin.st] 
Sent: 25 November 2017 21:13
To: mingw-w64-public@lists.sourceforge.net
Subject: [Mingw-w64-public] [PATCH] ucrtbase: Don't include a import library 
alias "tzset"

This was missed in 483ddaaf1b09590756ff8c59bc2db7501d7364f9.

Signed-off-by: Martin Storsjö 
---
 mingw-w64-crt/def-include/msvcrt-common.def.in | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/mingw-w64-crt/def-include/msvcrt-common.def.in 
b/mingw-w64-crt/def-include/msvcrt-common.def.in
index 9fb8dc2..c0418fc 100644
--- a/mingw-w64-crt/def-include/msvcrt-common.def.in
+++ b/mingw-w64-crt/def-include/msvcrt-common.def.in
@@ -92,7 +92,9 @@ ADD_UNDERSCORE(strupr)
 ADD_UNDERSCORE(swab)
 ADD_UNDERSCORE(tell)
 ADD_UNDERSCORE(tempnam)
+#ifndef UCRTBASE
 ADD_UNDERSCORE(tzset)
+#endif
 ADD_UNDERSCORE(umask)
 ADD_UNDERSCORE(ungetch)
 ADD_UNDERSCORE(unlink)
-- 
2.7.4



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [PATCH] ucrtbase: Make sure that compat symbols aren't autoexported

2017-11-25 Thread Sven Kretzschmar

Hi Martin,

Thanks for your WIP stdio_s.h . That helped a lot.
I had to add another func (swprintf_s) & I had to comment out 3 of your wip
functions, because there is no "__stdio_common_vfscanf_s" internal
func in MS ucrtbase.
I have attached my modified stdio_s.h & wchar_s.h file if you want to have a
look if I did that right. 
Changes are framed - a bit unorthodox - by /* NEW SK */ ...

However, I am getting a new error now, when compiling Julia sources with the
ucrtbase version of gcc - see below ERROR #4.
I think you mentioned somewhere that you excluded "tzset" from the "ucrtbase
autoexport" patch, because this led to an
"infinite recursion" or similar.
But by looking at the below error, it seems that it is still needed to be
excluded somehow.

Do you have any ideas for an additional/different patch to address this ?
(Preferably not requiring to explicitly exclude linkage via -Wl linker
flags, as all this is happing somewhere deep inside the big Makefile & CMake
build system for Julia ?

Thanks & Cheers
- Sven

ERROR #4:
--
/CROSS64/lib/gcc/x86_64-w64-mingw32/6.4.0/../../../../x86_64-w64-mingw32/lib
/../lib/libmsvcrt.a(lib64_libucrtbase_a-ucrtbase_compat.o): In function
`tzset':
/home/sven/buildtmp/build/mingw-crt/../../src/mingw-w64/mingw-w64-crt/crt/uc
rtbase_compat.c:178: multiple definition of `tzset'
/CROSS64/lib/gcc/x86_64-w64-mingw32/6.4.0/../../../../x86_64-w64-mingw32/lib
/../lib/libmsvcrt.a(dumns02036.o):(.text+0x0): first defined here
/CROSS64/lib/gcc/x86_64-w64-mingw32/6.4.0/../../../../x86_64-w64-mingw32/lib
/../lib/libmsvcrt.a(lib64_libucrtbase_a-ucrtbase_compat.o):/home/sven/buildt
mp/build/mingw-crt/../../src/mingw-w64/mingw-w64-crt/crt/ucrtbase_compat.c:2
36: multiple definition of `__imp_tzset'
/CROSS64/lib/gcc/x86_64-w64-mingw32/6.4.0/../../../../x86_64-w64-mingw32/lib
/../lib/libmsvcrt.a(dumns02036.o):(.idata$5+0x0): first defined here
collect2: error: ld returned 1 exit status

-Original Message-
From: Martin Storsjö [mailto:mar...@martin.st] 
Sent: 24 November 2017 13:02
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] [PATCH] ucrtbase: Make sure that compat
symbols aren't autoexported

On Thu, 23 Nov 2017, Sven Kretzschmar wrote:

> I will try to add the 2 missing references in the way you hinted at in 
> your post.

FWIW, for the _cprintf one, the conio.h patch that I sent should be a proper
fix.

The other one requires fixing stdio_s.h, and it's a truly huge number of
functions there. I started looking at it, but don't have time to do them all
right now. Attached is my work in progress for this header, that should
cover at least the function that you mentioned so far.

That one isn't sent for review yet as it's quite incomplete. OTOH, perhaps
it's better to at least fix up some subsets of it, that happens to be used,
instead of aiming for all of them.

// Martin
/**
 * This file has no copyright assigned and is placed in the Public Domain.
 * This file is part of the mingw-w64 runtime package.
 * No warranty is given; refer to the file DISCLAIMER.PD within this package.
 */
#ifndef _INC_WCHAR_S
#define _INC_WCHAR_S

#include 

#if defined(MINGW_HAS_SECURE_API)

#if defined(__LIBMSVCRT__)
/* When building mingw-w64, this should be blank.  */
#define _SECIMP
#else
#ifndef _SECIMP
#define _SECIMP __declspec(dllimport)
#endif /* _SECIMP */
#endif /* defined(_CRTBLD) || defined(__LIBMSVCRT__) */

#ifdef __cplusplus
extern "C" {
#endif

/* NEW SK */
#if __MSVCRT_VERSION__ >= 0x1400
  int __cdecl __stdio_common_vswprintf_s(unsigned __int64 Options, wchar_t 
*Str, size_t Len, const wchar_t *Format, _locale_t _Locale, va_list _ArgList);
#endif
/* NEW SK */

#ifndef _WIO_S_DEFINED
#define _WIO_S_DEFINED
  _SECIMP errno_t __cdecl _waccess_s (const wchar_t *_Filename,int _AccessMode);
  _SECIMP errno_t __cdecl _wmktemp_s (wchar_t *_TemplateName,size_t 
_SizeInWords);
#endif

#ifndef _WCONIO_S_DEFINED
#define _WCONIO_S_DEFINED
  _SECIMP errno_t __cdecl _cgetws_s (wchar_t *_Buffer,size_t 
_SizeInWords,size_t *_SizeRead);
  _SECIMP int __cdecl _cwprintf_s (const wchar_t *_Format,...);
  _CRTIMP int __cdecl _cwscanf_s(const wchar_t *_Format,...);
  _CRTIMP int __cdecl _cwscanf_s_l(const wchar_t *_Format,_locale_t 
_Locale,...);
  _SECIMP int __cdecl _vcwprintf_s (const wchar_t *_Format,va_list _ArgList);
  _SECIMP int __cdecl _cwprintf_s_l (const wchar_t *_Format,_locale_t 
_Locale,...);
  _SECIMP int __cdecl _vcwprintf_s_l (const wchar_t *_Format,_locale_t 
_Locale,va_list _ArgList);
#endif

#ifndef _WSTDIO_S_DEFINED
#define _WSTDIO_S_DEFINED
  _CRTIMP wchar_t *__cdecl _getws_s(wchar_t *_Str,size_t _SizeInWords);
  int __cdecl fwprintf_s(FILE *_File,const wchar_t *_Format,...);
  int __cdecl wprintf_s(const wchar_t *_Format,...);
  int __cdecl vfwprintf_s(FILE *_File,const wchar_t *_Format,va_list _ArgList);
  int __cdecl vwprintf_s(const wchar_t *_Format,va_list _A

Re: [Mingw-w64-public] [PATCH] ucrtbase: Make sure that compat symbols aren't autoexported

2017-11-23 Thread Sven Kretzschmar

Hi Martin,

Thanks a lot for your support in getting ucrtbase to work.

I will try to add the 2 missing references in the way you hinted at in your
post.


Currently I get a new strange error while compiling the Julia sources with
the new toolchain:

/CROSS64/lib/gcc/x86_64-w64-mingw32/6.4.0/../../../../x86_64-w64-mingw32/lib
/../lib/libmsvcrt.a(lib64_libucrtbase_a-ucrt_sprintf.o):/home/sven/buildtmp/
build/mingw-crt/../../src/mingw-w64/mingw-w64-crt/stdio/ucrt_sprintf.c:20:
multiple definition of `__imp_snprintf'
/CROSS64/lib/gcc/x86_64-w64-mingw32/6.4.0/../../../../x86_64-w64-mingw32/lib
/../lib/libmsvcrt.a(lib64_libucrtbase_a-ucrt_snprintf.o):/home/sven/buildtmp
/build/mingw-crt/../../src/mingw-w64/mingw-w64-crt/stdio/ucrt_snprintf.c:20:
first defined here


Is it possible that your last ucrtbase patch contained a typo ? :

diff --git a/mingw-w64-crt/stdio/ucrt_sprintf.c
b/mingw-w64-crt/stdio/ucrt_sprintf.c
index 74d665d..b9029d5 100644
--- a/mingw-w64-crt/stdio/ucrt_sprintf.c
+++ b/mingw-w64-crt/stdio/ucrt_sprintf.c
@@ -17,3 +17,4 @@ int __cdecl sprintf(char * __restrict__ _Dest,const char *
__restrict__ _Format,
   __builtin_va_end(ap);
   return ret;
 }
+int __cdecl (*__MINGW_IMP_SYMBOL(snprintf))(char *__restrict__, const
<== Typo here ? (snprintf -> sprintf) ?  ***
+char *__restrict__, ...) = sprintf;


Thanks & Cheers
- Sven

-Original Message-
From: Martin Storsjö [mailto:mar...@martin.st] 
Sent: 23 November 2017 12:15
To: Kai Tietz via Mingw-w64-public 
Subject: Re: [Mingw-w64-public] [PATCH] ucrtbase: Make sure that compat
symbols aren't autoexported

On Thu, 23 Nov 2017, Martin Storsjö wrote:

> On Thu, 23 Nov 2017, Kai Tietz via Mingw-w64-public wrote:
>
>> Martin,
>> 
>> patch looks ok.  Be careful about the static symbol in custom section 
>> that it is actually present in a finally linked version.  Sometimes 
>> gcc thinks ... that it can optimize away such static symbols.  I had 
>> to introduce for that dummy references to such symbols in the past.
>> See crt/* folder for that.
>
> Yup, in this case I used __attribute__((__used__)) for that.
>
> // Martin

Pushed - with one minor adjustment (we didn't need any
__MINGW_IMP_SYMBOL(_tzset), and by adding one it would recurse infinitely).

// Martin

--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Challenges with using ucrtbase option for cross compiling...

2017-11-22 Thread Sven Kretzschmar

Ok - I stopped trying to bootstrap the new gcc compiler with ucrtbase option
& returned to the non-bootstrapped build (with ucrt default option), 
which built libiberty correctly now.

However, at the very end of the build process, I receive the following error
again:

ERROR #1:
--
libtool: link: rm -fr  .libs/libgfortran.dll.a
.libs/libgfortran.la.lnkscript
libtool: link: /home/sven/buildtmp/build/gcc/./gcc/xgcc
-B/home/sven/buildtmp/build/gcc/./gcc/ -L/CROSS64/x86_64-w64-mingw32/lib
-L/CROSS64/mingw/lib -isystem /CROSS64/x86_64-w64-mingw32/include -isystem
/CROSS64/mingw/include -B/CROSS64/x86_64-w64-mingw32/bin/
-B/CROSS64/x86_64-w64-mingw32/lib/ -isystem
/CROSS64/x86_64-w64-mingw32/include -isystem
/CROSS64/x86_64-w64-mingw32/sys-include-shared
.libs/libgfortran.la.lnkscript -Wl,--whole-archive
../libbacktrace/.libs/libbacktrace.a -Wl,--no-whole-archive
-L/CROSS64/x86_64-w64-mingw32/lib -L/CROSS64/mingw/lib
../libquadmath/.libs/libquadmath.dll.a  -shared-libgcc   -o
.libs/libgfortran-3.dll -Wl,--enable-auto-image-base -Xlinker --out-implib
-Xlinker .libs/libgfortran.dll.a
/CROSS64/x86_64-w64-mingw32/lib/libmsvcrt.a(lib64_libucrtbase_a-ucrtbase_com
pat.o): In function `_amsg_exit':
/home/sven/buildtmp/build/mingw-crt/../../src/mingw-w64/mingw-w64-crt/crt/uc
rtbase_compat.c:115: multiple definition of `_amsg_exit'
../libquadmath/.libs/libquadmath.dll.a(d32.o):(.text+0x0): first defined
here

nm confirms the problem:
$ nm libquadmath.dll.a | grep -i _amsg_exit
 I __imp__amsg_exit
 T _amsg_exit <== !

I checked around a bit, and it seems that this has to do with the fact that
instead of directly using the normal (old) msvcrt, the build process now
uses ucrtbase + ucrtbase_compat as "msvcrt".
This somehow leads to different behaviour when linking .dll.a import libs in
the build process with the ucrtbase option.

Using objcopy -N, I then decided to just strip the unwanted _amsg_exit
symbol from libquadmath.dll.a, just to be able to finish the build (that
worked ;)
Then I installed the ucrt-based GCC/Fortran compiler toolchain.

I have checked ...mingw64...-crt/include/internal.h ,
mingw64...-crt/crt/ucrtbase_compat.c  and mingw64...-headers/crt/_mingwh.in
, but could not see obvious fixes for this problem.

Question:
-
==> Does somebody with more knowledge about the mingw64 sources / internal
functionality has any ideas about possible causes for this ?


ERROR #2 (#1a...):

Using the new compiler toolchain to compile the Julia language from sources,
I get the following errors, related to ERROR #1 above:
/CROSS64/lib/gcc/x86_64-w64-mingw32/6.4.0/../../../../x86_64-w64-mingw32/lib
/../lib/libmsvcrt.a(lib64_libucrtbase_a-ucrtbase_compat.o):
  In function `__getmainargs':
 
/home/sven/buildtmp/build/mingw-crt/../../src/mingw-w64/mingw-w64-crt/crt/uc
rtbase_compat.c:73:
  multiple definition of `__getmainargs'
 
/CROSS64/lib/gcc/x86_64-w64-mingw32/6.4.0/libstdc++.dll.a(d005922.o):(.text+
0x0):
  first defined here

 
/CROSS64/lib/gcc/x86_64-w64-mingw32/6.4.0/../../../../x86_64-w64-mingw32/lib
/../lib/libmsvcrt.a(lib64_libucrtbase_a-ucrtbase_compat.o):
  In function `_amsg_exit':
 
/home/sven/buildtmp/build/mingw-crt/../../src/mingw-w64/mingw-w64-crt/crt/uc
rtbase_compat.c:116:
  multiple definition of `_amsg_exit'
 
/CROSS64/lib/gcc/x86_64-w64-mingw32/6.4.0/libstdc++.dll.a(d005927.o):(.text+
0x0):
  first defined here

It seems that the symbols from ucrtbase_compat.c not only ended up in
libquadmath.dll.a, but also in other *.dll.a :
e.g.:
sven@BigWin /CROSS64/lib/gcc/x86_64-w64-mingw32/6.4.0
$ nm libstdc++.dll.a | grep -i _amsg_exit
 I __imp__amsg_exit
 T _amsg_exit   <== !

$ nm libstdc++.dll.a | grep -i __getmainargs
 T __getmainargs<== !
 I __imp___getmainargs

$ nm libssp.dll.a | grep -i __getmainargs
 T __getmainargs   <== !
 I __imp___getmainargs

$ nm libssp.dll.a | grep -i _amsg_exit
 I __imp__amsg_exit
 T _amsg_exit<== !

Question:
-
==> Any idea why this happens when building gcc with the
"--with-default-msvcrt=ucrtbase" option ?


ERROR #3:
--
I am getting undefined references during compilation of Julia sources:
../libopenblas64_p-r0.2.19.a(memory.obj):memory.c:(.text+0x493): undefined
reference to `__imp__cprintf'
CMakeFiles/mbedcrypto.dir/objects.a(platform.c.obj):platform.c:(.text+0x3b):
undefined reference to `__imp__vsnprintf_s'

This might have to do with a wrong configuration of the "_CRTIMP" definition
in some places in mingw64 for the ucrtbase option, but I am not sure...


Thanks for any ideas or hints.

Cheers
- Sven

-Original Message-
From: Sven Kretzschmar [mailto:sven.kretzsch...@gmx.

Re: [Mingw-w64-public] Challenges with using ucrtbase option for cross compiling...

2017-11-21 Thread Sven Kretzschmar

It seems the real problem is that the build tries to compile "pex-unix.c" in
the liberty sources instead
of "pex-win32.c". And this in a build stage where the new
x86_64-w64-mingw32-gcc & environment
is already used.
That points in the direction of a perhaps buggy configure script in the case
of a bootstrapping build
of gcc using libiberty.
Maybe Cygwin is more unix-like than mingw64 & this causes confusion during
the bootstrap stages...
Will check further along this path...

-Original Message-
From: Sven Kretzschmar [mailto:sven.kretzsch...@gmx.de] 
Sent: 21 November 2017 22:03
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] Challenges with using ucrtbase option for
cross compiling...

I have changed the gcc build mode from --disable-bootstrap to
--enable-bootstrap with the last build.
(That's normally the correct way, the --disable-bootstrap slipped in
accidentally from earlier tests.) The missing defines are nowhere in the
"raw" mingw64 distribution, so I assume libiberty would not build with
x86_64-w64-mingw32-gcc with or without ucrtbase (when using the correct
x86_64-w64-mingw32 CROSS include directory).

With bootstrapping enabled, the build process will use the newly built gcc
as soon as possible for following build steps, also using the CROSS include
dirs. with the missing defines in/via fcntl.h.

The reason it built before was that I did not enable bootstrapping, which
resulted in the new gcc being build completely with the Cygwin-gcc &
corresponding include dirs (as this is my build environment).
In the Cygwin /usr/include/fcntl.h header those symbols are indirectly
included via another header. 
So libiberty compiled without errors in this case.

libiberty.a was built in the very first step for binutils via Cygwin-gcc (as
there was no x86_64-w64-mingw32-gcc at that time). So I just have to bring
the bootstrapping build of gcc to use that one instead of trying to build a
new version.
There is an old discussion about that & the needed option in:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56780
I will try it that way & inform about my results.

(But I am still a bit uneasy about those missing fcntl.h defines in the
mingw64 source distribution.
I might also try to rebuild without ucrtbase, just to test if it really
fails too, as expected.)

Cheers
- Sven

-Original Message-
From: Martin Storsjö [mailto:mar...@martin.st]
Sent: 21 November 2017 21:02
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] Challenges with using ucrtbase option for
cross compiling...

On Tue, 21 Nov 2017, Sven Kretzschmar wrote:

> Thanks - now the cross compilation goes much further resulting in the 
> below error (trying to cross-compile x86_64-w64-mingw32-gcc with 
> libiberty support & ucrtbase option, other options as before, 
> bootstrapping enabled).
>
> Normally, the undeclared symbols (e.g. F_GETFD, F_SETFD, F_DUPFD, ...) 
> are declared in "fcntl.h" or in header files included from "fcntl.h".
> However, in the mingw64 distribution, "fcntl.h" does not contain or 
> include these symbols. Therefore the below errors result...
>
> Did I overlook something ? Is this a bug or a feature (intended) or 
> was it missed/postponed ?

No idea, I haven't touched any such headers wrt ucrtbase. So it sounds like
some other feature detection goes differently than before, which means that
it now tries to build this code. In the default build that succeeds (without
ucrtbase), does it try to build these files at all?

> Maybe I can get around this by trying to compile gcc without libiberty 
> support, but I am suspicious that the missing defines might cause 
> problems later in other places...

Nah, I'd recommend trying to dig into and see why you're running into this
issue instead of trying to sidestep it.

> Other subject:
> Using clang with mingw64 instead of gcc to compile Julia (The Julia
> language) sounds like an interesting alternative, however getting 
> Julia compiled with all its dependencies (including fortran sources) 
> with clang instead of gcc would be a huge effort, if at all possible.

Yes, the clang/llvm based toolchain is much less mature in all aspects, so I
wouldn't recommend it unless you have interest in it for another reason (my
reason is support for windows on non-x86 platforms).

// Martin

--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Check out the vibrant tech community on one

Re: [Mingw-w64-public] Challenges with using ucrtbase option for cross compiling...

2017-11-21 Thread Sven Kretzschmar

I have changed the gcc build mode from --disable-bootstrap to
--enable-bootstrap with the last build.
(That's normally the correct way, the --disable-bootstrap slipped in
accidentally from earlier tests.)
The missing defines are nowhere in the "raw" mingw64 distribution, so I
assume libiberty would not build
with x86_64-w64-mingw32-gcc with or without ucrtbase (when using the correct
x86_64-w64-mingw32 CROSS include directory).

With bootstrapping enabled, the build process will use the newly built gcc
as soon as possible for following build steps,
also using the CROSS include dirs. with the missing defines in/via fcntl.h.

The reason it built before was that I did not enable bootstrapping, which
resulted in the new gcc being build
completely with the Cygwin-gcc & corresponding include dirs (as this is my
build environment).
In the Cygwin /usr/include/fcntl.h header those symbols are indirectly
included via another header. 
So libiberty compiled without errors in this case.

libiberty.a was built in the very first step for binutils via Cygwin-gcc (as
there was no x86_64-w64-mingw32-gcc at
that time). So I just have to bring the bootstrapping build of gcc to use
that one instead of trying to build a new version.
There is an old discussion about that & the needed option in:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56780
I will try it that way & inform about my results.

(But I am still a bit uneasy about those missing fcntl.h defines in the
mingw64 source distribution.
I might also try to rebuild without ucrtbase, just to test if it really
fails too, as expected.)

Cheers
- Sven

-Original Message-
From: Martin Storsjö [mailto:mar...@martin.st] 
Sent: 21 November 2017 21:02
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] Challenges with using ucrtbase option for
cross compiling...

On Tue, 21 Nov 2017, Sven Kretzschmar wrote:

> Thanks - now the cross compilation goes much further resulting in the 
> below error (trying to cross-compile x86_64-w64-mingw32-gcc with 
> libiberty support & ucrtbase option, other options as before, 
> bootstrapping enabled).
>
> Normally, the undeclared symbols (e.g. F_GETFD, F_SETFD, F_DUPFD, ...) 
> are declared in "fcntl.h" or in header files included from "fcntl.h".
> However, in the mingw64 distribution, "fcntl.h" does not contain or 
> include these symbols. Therefore the below errors result...
>
> Did I overlook something ? Is this a bug or a feature (intended) or 
> was it missed/postponed ?

No idea, I haven't touched any such headers wrt ucrtbase. So it sounds like
some other feature detection goes differently than before, which means that
it now tries to build this code. In the default build that succeeds (without
ucrtbase), does it try to build these files at all?

> Maybe I can get around this by trying to compile gcc without libiberty 
> support, but I am suspicious that the missing defines might cause 
> problems later in other places...

Nah, I'd recommend trying to dig into and see why you're running into this
issue instead of trying to sidestep it.

> Other subject:
> Using clang with mingw64 instead of gcc to compile Julia (The Julia
> language) sounds like an interesting alternative, however getting 
> Julia compiled with all its dependencies (including fortran sources) 
> with clang instead of gcc would be a huge effort, if at all possible.

Yes, the clang/llvm based toolchain is much less mature in all aspects, so I
wouldn't recommend it unless you have interest in it for another reason (my
reason is support for windows on non-x86 platforms).

// Martin

--
Check out the vibrant tech community on one of the world's most engaging
tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Challenges with using ucrtbase option for cross compiling...

2017-11-21 Thread Sven Kretzschmar

Thanks - now the cross compilation goes much further resulting in the below
error
(trying to cross-compile x86_64-w64-mingw32-gcc with libiberty support &
ucrtbase option, other options as before, bootstrapping enabled).

Normally, the undeclared symbols (e.g. F_GETFD, F_SETFD, F_DUPFD, ...) are
declared in "fcntl.h" or in header files included from "fcntl.h".
However, in the mingw64 distribution, "fcntl.h" does not contain or include
these symbols. Therefore the below errors result...

Did I overlook something ? Is this a bug or a feature (intended) or was it
missed/postponed ?

Maybe I can get around this by trying to compile gcc without libiberty
support, but I am suspicious that the missing defines might
cause problems later in other places...

Thanks for having a short look or any further hint :)


Other subject:
Using clang with mingw64 instead of gcc to compile Julia (The Julia
language) sounds like an interesting alternative, however
getting Julia compiled with all its dependencies (including fortran sources)
with clang instead of gcc would be a huge effort, if at all possible.
So I hope getting the gnu toolchain to work with mingw64 & ucrtbase will be
much easier & help other projects too - at least it
seems to be very close now (famous last words... ;).


ERROR msg in last step of cross build ("make" for gcc):

/home/sven/buildtmp/build/gcc/./prev-gcc/xgcc
-B/home/sven/buildtmp/build/gcc/./prev-gcc/
-B/CROSS64/x86_64-w64-mingw32/bin/ -L/CROSS64/x86_64-w64-mingw32/lib
-L/CROSS64/mingw/lib -isystem /CROSS64/x86_64-w64-mingw32/include -isystem
/CROSS64/mingw/include -B/CROSS64/x86_64-w64-mingw32/bin/
-B/CROSS64/x86_64-w64-mingw32/lib/ -isystem
/CROSS64/x86_64-w64-mingw32/include -isystem
/CROSS64/x86_64-w64-mingw32/sys-include-c -DHAVE_CONFIG_H -g -O2
-gtoggle  -I. -I../../../src/gcc/libiberty/../include  -W -Wall
-Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic  -D_GNU_SOURCE
../../../src/gcc/libiberty/pex-unix.c -o pex-unix.o
../../../src/gcc/libiberty/pex-unix.c: In function 'pex_wait':
../../../src/gcc/libiberty/pex-unix.c:257:14: warning: implicit declaration
of function 'wait' [-Wimplicit-function-declaration]
   cpid = wait (status);
  ^~~~
../../../src/gcc/libiberty/pex-unix.c: At top level:
../../../src/gcc/libiberty/pex-unix.c:326:3: warning: initialization from
incompatible pointer type [-Wincompatible-pointer-types]
   pex_unix_wait,
   ^
../../../src/gcc/libiberty/pex-unix.c:326:3: note: (near initialization for
'funcs.wait')
../../../src/gcc/libiberty/pex-unix.c: In function 'save_and_install_fd':
../../../src/gcc/libiberty/pex-unix.c:407:11: warning: implicit declaration
of function 'fcntl' [-Wimplicit-function-declaration]
   flags = fcntl (old_fd, F_GETFD);
   ^
../../../src/gcc/libiberty/pex-unix.c:407:26: error: 'F_GETFD' undeclared
(first use in this function)
   flags = fcntl (old_fd, F_GETFD);
  ^~~
../../../src/gcc/libiberty/pex-unix.c:407:26: note: each undeclared
identifier is reported only once for each function it appears in
../../../src/gcc/libiberty/pex-unix.c:420:20: error: 'FD_CLOEXEC' undeclared
(first use in this function)
   if ((flags & FD_CLOEXEC) == 0 && fcntl (old_fd, F_SETFD, FD_CLOEXEC)
< 0)
^~
../../../src/gcc/libiberty/pex-unix.c:420:55: error: 'F_SETFD' undeclared
(first use in this function)
   if ((flags & FD_CLOEXEC) == 0 && fcntl (old_fd, F_SETFD, FD_CLOEXEC)
< 0)
   ^~~
../../../src/gcc/libiberty/pex-unix.c:433:31: error: 'F_DUPFD' undeclared
(first use in this function)
   new_fd = fcntl (old_fd, F_DUPFD, 3);
   ^~~
../../../src/gcc/libiberty/pex-unix.c: In function 'restore_fd':
../../../src/gcc/libiberty/pex-unix.c:467:19: error: 'FD_CLOEXEC' undeclared
(first use in this function)
   if (flags & FD_CLOEXEC)
   ^~
../../../src/gcc/libiberty/pex-unix.c:469:29: error: 'F_SETFD' undeclared
(first use in this function)
   return fcntl (old_fd, F_SETFD, flags);

-Original Message-
From: Martin Storsjö [mailto:mar...@martin.st] 
Sent: 21 November 2017 09:14
To: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] Challenges with using ucrtbase option for
cross compiling...

On Mon, 20 Nov 2017, Sven Kretzschmar wrote:

> Hi,
>
> Thanks a lot for all your work on this project ! :)
>
> I am using the newest master branch of mingw64 from 
> https://github.com/mirror/mingw-w64/tree/master .
> GCC version used is:
> https://github.com/gcc-mirror/gcc/tree/gcc-6_4_0-release  (6.4.0) And 
> the newest version of all other needed libs.
> Also I am using cygwin64 with x86_64-pc-cygwin-gcc and the necessary 
> devel packages (except mingw64).
>
> I am trying to cross-com

[Mingw-w64-public] Challenges with using ucrtbase option for cross compiling...

2017-11-20 Thread Sven Kretzschmar

Hi,

Thanks a lot for all your work on this project ! :)

I am using the newest master branch of mingw64 from
https://github.com/mirror/mingw-w64/tree/master .
GCC version used is:
https://github.com/gcc-mirror/gcc/tree/gcc-6_4_0-release  (6.4.0)
And the newest version of all other needed libs.
Also I am using cygwin64 with x86_64-pc-cygwin-gcc and the necessary devel
packages (except mingw64).

I am trying to cross-compile targeting a mingw64 toolchain (binutils, gcc,
runtime,.) which is based on ucrtbase instead of msvcrt.
Motivation is that I want to compile Julia ( https://julialang.org/ ) so
that the compiled dlls and binaries are dependent on ucrtbase.dll
and not on msvcrt.dll which enables for easier embedding in another program
which was compiled with MS VS 2015.
(-> no trouble with incompatible file descriptors, stdin/out/err, memory
management, etc.)
Julia: https://github.com/JuliaLang/julia/tree/v0.6.1

Julia is best compiled on Windows with cygwin64 (Compilation via MSYS2 seems
to be broken currently & MS VC not possible)

When targeting ucrtbase, I get 3 errors & am unable to finish the build.


Questions:
--
==> Are there any ideas on how to fix this, or is an ucrtbase build not yet
usable/possible with Mingw64 ?
==> Can you indicate which versions of gcc / binutils you are using 
to test the ucrtbase build option and post which configure options you are
using for:
- gcc
- mingw64-headers
- mingw64.crt
- binutils
This could help a lot to check/debug & get a successful ming64 cross build
with ucrtbase option. Thanks :))
 

Here are my configures for 
Mingw64-headers:
../../src/mingw-w64/mingw-w64-headers/configure
--prefix=/CROSS64/x86_64-w64-mingw32 --build=x86_64-pc-cygwin
--target=x86_64-w64-mingw32 --enable-sdk=all --enable-secure-api
--enable-idl --without-widl --with-default-msvcrt=ucrtbase

Mingw64-crt:
../../src/mingw-w64/mingw-w64-crt/configure
--prefix=/CROSS64/x86_64-w64-mingw32
--with-sysroot=/CROSS64/x86_64-w64-mingw32 --build=x86_64-pc-cygwin
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --enable-lib64
--disable-lib32 --enable-wildcard --with-default-msvcrt=ucrtbase

Gcc:
../../src/gcc/configure --prefix=/CROSS64 --build=x86_64-pc-cygwin
--target=x86_64-w64-mingw32 --with-sysroot=/CROSS64 --with-gmp=/support
--with-mpfr=/support --with-mpc=/support
--enable-languages=c,c++,fortran,lto --disable-multilib
--disable-win32-registry --enable-fully-dynamic-string --enable-graphite
--enable-libgomp --enable-libquadmath --enable-libquadmath-support
--enable-libssp --enable-version-specific-runtime-libs --enable-libgomp
--with-dwarf2 --with-gnu-ld --with-gnu-as --with-tune=generic
--with-system-zlib --enable-threads=posix --disable-bootstrap
--with-native-system-header-dir=/x86_64-w64-mingw32/include
--with-arch=x86-64 --enable-shared --enable-static --enable-libatomic
--enable-libstdcxx-time=yes --disable-libstdcxx-pch
--disable-libstdcxx-debug --disable-isl-version-check --enable-lto
--enable-checking=release --disable-rpath --disable-nls --disable-werror
--with-libiconv --disable-symvers --enable-linker-build-id

Binutils:
../../src/binutils/configure --build=x86_64-pc-cygwin
--target=x86_64-w64-mingw32 --prefix=/CROSS64 --with-sysroot=/CROSS64
--disable-multilib --disable-werror --enable-lto --enable-64-bit-bfd
--enable-nls --disable-rpath --enable-install-libiberty --enable-plugins
--enable-gold --disable-shared --with-libiconv-prefix=/CROSS64

When I use the above configures _without_ the
"--with-default-msvcrt=ucrtbase" options, I can generate the whole toolchain
without problems & compile Julia.but with msvcrt.dll dependency.

When I use the above configure options, the following errors occur in the
last step of the cross-compile (roughly following the build recipe given
at:
https://github.com/mirror/mingw-w64/blob/master/mingw-w64-doc/howto-build/mi
ngw-w64-howto-build-adv.txt & others )

ERROR #1:
--
(executing "make" for gcc ):
Include dir: \x86_64-w64-mingw32\include:
Conflicting specifiers in declarations in time.h:  for difftime, ctime,
gmtime, ., time.
Conflicting specifiers in declarations in stdio.h: for fseek, fseeko, .,
ftelli64.
Conflicting specifiers in declarations in wchar.h: for _snwprintf.

=>It seems that the "__mingw_static_ovr" define is not expanded correctly.
If I replace it directly with its current content (quick & dirty.), it
compiles without errors:
#if !defined(__CRT__NO_INLINE) || __MSVCRT_VERSION__ >= 0x1400
#if __MSVCRT_VERSION__ >= 0x1400
#define __TIME_INLINE static __attribute__ ((__unused__)) __inline__
__attribute__((__cdecl__)) /*__mingw_static_ovr*/ <== Quick & dirty
fix..
#else
#define __TIME_INLINE __CRT_INLINE
#endif
#if !defined(_USE_32BIT_TIME_T)
__TIME_INLINE double __cdecl difftime(time_t _Time1,time_t _Time2)
  { return _difftime64(_Time1,_Time2); }
__TIME_INLINE char *__cdecl ctime(const time_t *_Time) { return
_ctime64(_Time); }
__TIME_INLINE struct tm *__cdecl gmtime(const time_t *_Time) { return

Re: [Mingw-w64-public] Challenges with using ucrtbase option for cross compiling...

Re: [Mingw-w64-public] [PATCH 2/2] Use public _acmdln and _wcmdln declarations in crt and get rid of no loner needed ucrtbase compat hack.

Re: [Mingw-w64-public] [PATCH] ucrtbase: Don't include a import library alias "tzset"

Re: [Mingw-w64-public] [PATCH] ucrtbase: Make sure that compat symbols aren't autoexported

Re: [Mingw-w64-public] [PATCH] ucrtbase: Make sure that compat symbols aren't autoexported

Re: [Mingw-w64-public] Challenges with using ucrtbase option for cross compiling...

Re: [Mingw-w64-public] Challenges with using ucrtbase option for cross compiling...

Re: [Mingw-w64-public] Challenges with using ucrtbase option for cross compiling...

Re: [Mingw-w64-public] Challenges with using ucrtbase option for cross compiling...

[Mingw-w64-public] Challenges with using ucrtbase option for cross compiling...

10 matches

Site Navigation

Mail list logo

Footer information