subject:"\[Mingw\-w64\-public\] building gcc"

Re: [Mingw-w64-public] Building gcc-10 against mingw-w64-8.0.0: error: unknown conversion type character 'l' in format

2021-01-19 Thread Sandro Mani




On 19.01.21 16:06, Biswapriyo Nath wrote:

Would you like to test if the following patch works?
* File name: 0020-libgomp-Don-t-hard-code-MS-printf-attributes.patch
* Link: 
https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/0020-libgomp-Don-t-hard-code-MS-printf-attributes.patch

ArchLinux also uses that patch file. Link
https://github.com/archlinux/svntogit-community/blob/packages/mingw-w64-gcc/trunk/PKGBUILD

Aforementioned links may be changed or removed in future.


Thanks for your quick replies, that patch worked.

Sandro



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Building gcc-10 against mingw-w64-8.0.0: error: unknown conversion type character 'l' in format

2021-01-19 Thread Liu Hao


在 2021-01-19 22:16, Sandro Mani 写道:

Hi

Tryting to build gcc-10 against mingw-w64-8.0.0, when compiling libgomp it 
errors out with [1]
(...)
 
-Werror is passed when compiling libgomp (as it generally is in gcc throughout), so this causes the 
build to fail. I'm unsure which is the correct approach to deal with this?





Please apply this patch [1] to GCC source tree and try again.

[1] 
https://github.com/lhmouse/MINGW-packages-dev/blob/3ac41bd0149bc354c9618b00df54746ea528adca/mingw-w64-gcc-git/0020-libgomp-Don-t-hard-code-MS-printf-attributes.patch




--
Best regards,
LH_Mouse
From 05b0bb43124b041da360ba9adcbaab8430be6d18 Mon Sep 17 00:00:00 2001
From: Liu Hao 
Date: Wed, 6 May 2020 21:49:18 +0800
Subject: [PATCH] libgomp: Don't hard-code MS printf attributes

---
 libgomp/libgomp.h | 13 ++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/libgomp/libgomp.h b/libgomp/libgomp.h
index c98c1452bd4..0cc8443f6c2 100644
--- a/libgomp/libgomp.h
+++ b/libgomp/libgomp.h
@@ -69,6 +69,13 @@
 # endif
 #endif
 
+#include 
+#ifdef __MINGW_PRINTF_FORMAT
+#define PRINTF_FORMAT __MINGW_PRINTF_FORMAT
+#else
+#define PRINTF_FORMAT printf
+#endif
+
 #ifdef HAVE_ATTRIBUTE_VISIBILITY
 # pragma GCC visibility push(hidden)
 #endif
@@ -180,7 +187,7 @@ extern void gomp_aligned_free (void *);
 
 extern void gomp_vdebug (int, const char *, va_list);
 extern void gomp_debug (int, const char *, ...)
-   __attribute__ ((format (printf, 2, 3)));
+   __attribute__ ((format (PRINTF_FORMAT, 2, 3)));
 #define gomp_vdebug(KIND, FMT, VALIST) \
   do { \
 if (__builtin_expect (gomp_debug_var, 0)) \
@@ -193,11 +200,11 @@ extern void gomp_debug (int, const char *, ...)
   } while (0)
 extern void gomp_verror (const char *, va_list);
 extern void gomp_error (const char *, ...)
-   __attribute__ ((format (printf, 1, 2)));
+   __attribute__ ((format (PRINTF_FORMAT, 1, 2)));
 extern void gomp_vfatal (const char *, va_list)
__attribute__ ((noreturn));
 extern void gomp_fatal (const char *, ...)
-   __attribute__ ((noreturn, format (printf, 1, 2)));
+   __attribute__ ((noreturn, format (PRINTF_FORMAT, 1, 2)));
 
 struct gomp_task;
 struct gomp_taskgroup;
-- 
2.26.2



OpenPGP_signature
Description: OpenPGP digital signature
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Building gcc-10 against mingw-w64-8.0.0: error: unknown conversion type character 'l' in format

2021-01-19 Thread Biswapriyo Nath

Would you like to test if the following patch works?
* File name: 0020-libgomp-Don-t-hard-code-MS-printf-attributes.patch
* Link: 
https://github.com/msys2/MINGW-packages/blob/master/mingw-w64-gcc/0020-libgomp-Don-t-hard-code-MS-printf-attributes.patch

ArchLinux also uses that patch file. Link
https://github.com/archlinux/svntogit-community/blob/packages/mingw-w64-gcc/trunk/PKGBUILD

Aforementioned links may be changed or removed in future.


___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Building gcc-10 against mingw-w64-8.0.0: error: unknown conversion type character 'l' in format

2021-01-19 Thread Sandro Mani


Hi

Tryting to build gcc-10 against mingw-w64-8.0.0, when compiling libgomp 
it errors out with [1]


In file included from ../../../libgomp/oacc-parallel.c:30:
../../../libgomp/oacc-parallel.c: In function 'GOACC_parallel_keyed':
../../../libgomp/oacc-parallel.c:122:18: error: unknown conversion type 
character 'l' in format [-Werror=format=]
  122 |   gomp_debug (0, "%s: mapnum=%"PRIu64", hostaddrs=%p, size=%p, 
kinds=%p\n",


(and more)

The reason being that with mingw-w64-8.0.0, in _mingw.h 
__USE_MINGW_ANSI_STDIO is now set to 1 (due to the "--->" lines here in 
_mingw.h:


    /* We are activating __USE_MINGW_ANSI_STDIO for various define 
indicators.
     * printf ll modifier (unsupported by msvcrt.dll) is required by 
C99 and C++11 standards. */
    #if (defined (_POSIX) || defined (_POSIX_SOURCE) || defined 
(_POSIX_C_SOURCE) \

     || defined (_ISOC99_SOURCE) \
--->     || (defined (__STDC_VERSION__) && __STDC_VERSION__ >= 199901L 
&& __MSVCRT_VERSION__ < 0xE00) \
--->     || (defined (__cplusplus) && __cplusplus >= 201103L && 
__MSVCRT_VERSION__ < 0xE00) \

     || defined (_XOPEN_SOURCE) || defined (_XOPEN_SOURCE_EXTENDED) \
     || defined (_GNU_SOURCE) \
     || defined (_SVID_SOURCE)) \
        && !defined(__USE_MINGW_ANSI_STDIO)
    /* Enable __USE_MINGW_ANSI_STDIO if user did _not_ specify it 
explicitly... */

    #  define __USE_MINGW_ANSI_STDIO    1
    #endif

), whereas mingw-w64-7.0.0 didn't enable __USE_MINGW_ANSI_STDIO for 
C99/C++11 (and hence this issue doesn't appear).


-Werror is passed when compiling libgomp (as it generally is in gcc 
throughout), so this causes the build to fail. I'm unsure which is the 
correct approach to deal with this?


Thanks for any pointers

Sandro

[1] https://kojipkgs.fedoraproject.org//work/tasks/9948/60029948/build.log



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Building GCC linked against libucrt fails

2019-04-01 Thread Martin Storsjö


On Mon, 1 Apr 2019, Kacvinsky, Tom wrote:


Hi,


I think the important distinction here is to make between building the
compiler itself (which is a binary which you build using your existing 
toolchain,
using the CRT that is default/usable there), and building the runtimes (libgcc,
libstdc++, libada) which the compiler will be using later.

The compiler itself can't be built linking to UCRT (which is what you are doing
in effect, even though you are linking to the old plain msvcrt.dll, and the
libgcc/libstdc++ you'll be linking also is for msvcrt.dll), but you only want to
build the runtimes (libgcc, libstdc++, libada) that way.

In my own setup for bootstrapping a mingw cross compiler on linux, I do the
following:

- Build binutils with --target=-w64-mingw32 --prefix=
- Install mingw-w64-headers with --prefix=/-w64-mingw32
- Build the compiler part of gcc with --target=-w64-mingw32
   --prefix= --enable-languges=c,c++, but only compile the compiler
   itself (by "make all-gcc; make install-gcc")
- Build the mingw-w64-crt with --prefix=/-w64-mingw32
   --host=-w64-mingw32
- Build the rest of gcc with "make; make install" in the gcc directory

I don't know if the gcc configure script has got a special place to inject extra
flags only for building the runtimes.

But setting up the newly installed mingw headers and crt with --with-default-
msvcrt= (especially if you are installing this into a separate sysroot different
from your existing compiler) should at least work, since the build of the
runtimes should end up using those headers.

Or maybe gcc has got a way of setting them separately from the flags for the
compiler itself?


OK, I built GCC as follows:

./configure --prefix=/mingw64 --enable-languages=c,c++,ada 
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 
--target=x86_64-w64-mingw32 --disable-multiarch   
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include

make all-gcc
make install-gcc

Then I built the MinGW-w64 CRT as follows

./configure --prefix=/mingw64/x86_64-w64-mingw32 --build=x86_64-w64-mingw32 
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --disable-multiarch  
--with-default-msvcrt=ucrt --disable-lib32 --with-libraries=all

make
make install

Then I went back to the GCC directory and ran
make

This failed.  IT for some reason wanted to go back to stage-1, and the 
--disable-multiarch is no longer in effect - it tried to build a 32-bit libgcc, 
which failed because it could find a 32-bit libkernel.a.  I don't want 32-bit 
support at this time.


I guess the problem is that you are trying to overwrite the current mingw 
installation, which presumably is in /mingw64/x86_64-w64-mingw32.


Did you install the headers also? you need to install crt and headers in 
sync.


When updating the files in /mingw64, which were already used for building 
the compiler itself, you trigger rebuilding of it because files used in 
the build have been updated. That's my guess of what's happening.


You probably need to do the gcc/mingw bootstrap into a different directory 
than the one you are using for building gcc itself, and then finally swap 
/mingw64 and the new mingw/gcc installation in the end. I do appreciate 
that this is a bit tricky if you have other files in there (installed by 
msys2) that you want brought along as well.


As for dual x86_64/i686 multiarch builds, unfortunately I don't know how 
to do them. I've only done both separately.


// Martin



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Building GCC linked against libucrt fails

2019-04-01 Thread Kacvinsky, Tom




> -Original Message-
> From: Kacvinsky, Tom 
> Sent: Monday, April 1, 2019 10:54 AM
> To: mingw-w64-public@lists.sourceforge.net
> Subject: [Mingw-w64-public] Building GCC linked against libucrt fails
> 
> > In my own setup for bootstrapping a mingw cross compiler on linux, I
> > do the
> > following:
> >
> > - Build binutils with --target=-w64-mingw32 --prefix=
> > - Install mingw-w64-headers with --prefix=/-w64-mingw32
> > - Build the compiler part of gcc with --target=-w64-mingw32
> >--prefix= --enable-languges=c,c++, but only compile the compiler
> >itself (by "make all-gcc; make install-gcc")
> > - Build the mingw-w64-crt with --prefix=/-w64-mingw32
> >--host=-w64-mingw32
> > - Build the rest of gcc with "make; make install" in the gcc directory
> >
> > I don't know if the gcc configure script has got a special place to
> > inject extra flags only for building the runtimes.
> >
> > But setting up the newly installed mingw headers and crt with
> > --with-default- msvcrt= (especially if you are installing this into a
> > separate sysroot different from your existing compiler) should at
> > least work, since the build of the runtimes should end up using those
> headers.
> >
> > Or maybe gcc has got a way of setting them separately from the flags
> > for the compiler itself?
> 
> OK, I built GCC as follows:
> 
> ./configure --prefix=/mingw64 --enable-languages=c,c++,ada --
> build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 --target=x86_64-
> w64-mingw32 --disable-multiarch   --with-native-system-header-
> dir=/mingw64/x86_64-w64-mingw32/include
> 
> make all-gcc
> make install-gcc
> 
> Then I built the MinGW-w64 CRT as follows
> 
> ./configure --prefix=/mingw64/x86_64-w64-mingw32 --build=x86_64-w64-
> mingw32 --host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --
> disable-multiarch  --with-default-msvcrt=ucrt --disable-lib32 --with-
> libraries=all
> 
> make
> make install
> 
> Then I went back to the GCC directory and ran make
> 
> This failed.  IT for some reason wanted to go back to stage-1, and the --
> disable-multiarch is no longer in effect - it tried to build a 32-bit libgcc, 
> which
> failed because it could find a 32-bit libkernel.a.  I don't want 32-bit 
> support at
> this time.
> 
> I am going to try without the Ada compiler in the mix and see what washes
> out but I don't have a good feeling about this.
> 
> Any ideas?


One of the other things I noted is that the MinGW-w64 CRT, when configured
without --disable-lib32 does not install the 32-bit libraries in a location 
where
the bootstrapped GCC can find the libraries.  Exactly where are the supposed
to be installed?  Could the MinGW-w64 CRT build process be changed so that
it can handle multi-arch installs?




___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Building GCC linked against libucrt fails

2019-04-01 Thread Kacvinsky, Tom

Hi,

> I think the important distinction here is to make between building the
> compiler itself (which is a binary which you build using your existing 
> toolchain,
> using the CRT that is default/usable there), and building the runtimes 
> (libgcc,
> libstdc++, libada) which the compiler will be using later.
> 
> The compiler itself can't be built linking to UCRT (which is what you are 
> doing
> in effect, even though you are linking to the old plain msvcrt.dll, and the
> libgcc/libstdc++ you'll be linking also is for msvcrt.dll), but you only want 
> to
> build the runtimes (libgcc, libstdc++, libada) that way.
> 
> In my own setup for bootstrapping a mingw cross compiler on linux, I do the
> following:
> 
> - Build binutils with --target=-w64-mingw32 --prefix=
> - Install mingw-w64-headers with --prefix=/-w64-mingw32
> - Build the compiler part of gcc with --target=-w64-mingw32
>--prefix= --enable-languges=c,c++, but only compile the compiler
>itself (by "make all-gcc; make install-gcc")
> - Build the mingw-w64-crt with --prefix=/-w64-mingw32
>--host=-w64-mingw32
> - Build the rest of gcc with "make; make install" in the gcc directory
> 
> I don't know if the gcc configure script has got a special place to inject 
> extra
> flags only for building the runtimes.
> 
> But setting up the newly installed mingw headers and crt with --with-default-
> msvcrt= (especially if you are installing this into a separate sysroot 
> different
> from your existing compiler) should at least work, since the build of the
> runtimes should end up using those headers.
> 
> Or maybe gcc has got a way of setting them separately from the flags for the
> compiler itself?

OK, I built GCC as follows:

./configure --prefix=/mingw64 --enable-languages=c,c++,ada 
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 
--target=x86_64-w64-mingw32 --disable-multiarch   
--with-native-system-header-dir=/mingw64/x86_64-w64-mingw32/include

make all-gcc
make install-gcc

Then I built the MinGW-w64 CRT as follows

./configure --prefix=/mingw64/x86_64-w64-mingw32 --build=x86_64-w64-mingw32 
--host=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --disable-multiarch  
--with-default-msvcrt=ucrt --disable-lib32 --with-libraries=all

make
make install

Then I went back to the GCC directory and ran
make

This failed.  IT for some reason wanted to go back to stage-1, and the 
--disable-multiarch is no longer in effect - it tried to build a 32-bit libgcc, 
which failed because it could find a 32-bit libkernel.a.  I don't want 32-bit 
support at this time.

I am going to try without the Ada compiler in the mix and see what washes out 
but I don't have a good feeling about this.

Any ideas?



___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Building GCC on mingw-w64

2015-10-23 Thread NightStrike

On Sat, Oct 3, 2015 at 6:46 PM, FX  wrote:
>> MSYS2 distributes the gcc fortran package based on mingw-w64 (see the
>> output of pacman -Ss fortran). You can inspect how it is built by
>> consulting its PKGBUILD recipe. It is here, along with the necessary
>> patches: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gcc
>
> Thanks for the pointer. It’s sad that mingw has regressed, when GCC trunk 
> used to build perfectly with no patch and configure options.
>
> I’m trying now to force the build triplet to x86_64-w64-mingw32, rather than 
> the detected value (x86_64-pc-mingw64).
> So I have another question: which is the expected/canonical build triplet?

Was that a typo, or did it really detect -mingw64 instead of mingw32?

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Building GCC on mingw-w64

2015-10-03 Thread FX

Hi everyone,

I’m a gcc contributor (gfortran maintainer), I haven’t hacked with mingw for a 
few years, but I’m getting back on the Windows horse to try to improve our 
testsuite results and performance on this target. Things have changed a lot 
since my last working setup (using mingw32 and old msys).

I tried to install a working mingw-w64 base on top of the MSYS2 shell, on a Win 
7 64-bit virtual machine, by:

  1. running the 64-bit MSYS2 installer at https://msys2.github.io
  2. installing (with “pacman -S”) the following packages: svn make 
mingw-w64-x86_64-gcc (full list of installed packages attached below)
  3. downloading gcc trunk
  4. ../gcc-trunk/configure --prefix=/home/FX/irun 
--enable-languages=c,c++,fortran --disable-bootstrap && make

After step 4, the build dies with the following error:

make[2]: Entering directory '/home/FX/ibin/fixincludes'
gcc -c -g -O2 -D__USE_MINGW_ACCESS -W -Wall -Wwrite-strings -Wstrict-prototypes 
-Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute 
-Wno-overlength-strings -pedantic -Wno-long-long   -DHAVE_CONFIG_H -I. 
-I../../gcc-trunk/fixincludes -I../include 
-I../../gcc-trunk/fixincludes/../include ../../gcc-trunk/fixincludes/fixincl.c
../../gcc-trunk/fixincludes/fixincl.c:29:22: fatal error: sys/wait.h: No such 
file or directory
compilation terminated.
Makefile:76: recipe for target 'fixincl.o' failed
make[2]: *** [fixincl.o] Error 1
make[2]: Leaving directory '/home/FX/ibin/fixincludes'
Makefile:3509: recipe for target 'all-fixincludes' failed
make[1]: *** [all-fixincludes] Error 2
make[1]: Leaving directory '/home/FX/ibin'
Makefile:879: recipe for target 'all' failed
make: *** [all] Error 2


and indeed, there is no sys/wait.h file under /mingw64/*/include.

I’ve tried to replace the configure line (step 4) by adding 
--with-sysroot=/mingw64/x86_64-w64-mingw32 but it didn’t change anything.

Am I missing something? Thanks for any hint or help.

FX





-- output of “pacman -Q”:

apr 1.5.1-1
apr-util 1.5.4-1
bash 4.3.042-1
bash-completion 2.1-6
bsdcpio 3.1.2-5
bsdtar 3.1.2-5
bzip2 1.0.6-2
ca-certificates 20150426-1
catgets 1.1-2
coreutils 8.24-1
crypt 1.1-6
curl 7.44.0-1
dash 0.5.8-1
expat 2.1.0-2
file 5.24-1
filesystem 2015.04-3
findutils 4.5.14-4
flex 2.5.39-4
gawk 4.1.3-1
gcc-libs 4.9.2-5
gettext 0.19.6-1
gmp 6.0.0-3
gnupg 1.4.19-1
grep 2.21-1
gzip 1.6-1
heimdal-libs 1.5.3-6
icu 51.2-2
inetutils 1.9.2-1
info 6.0-1
less 481-1
libarchive 3.1.2-5
libasprintf 0.19.6-1
libbz2 1.0.6-2
libcatgets 1.1-2
libcrypt 1.1-6
libcurl 7.44.0-1
libdb 5.3.28-2
libexpat 2.1.0-2
libffi 3.2.1-1
libgettextpo 0.19.6-1
libiconv 1.14-2
libidn 1.32-1
libintl 0.19.6-1
liblzma 5.2.1-1
liblzo2 2.09-1
libmetalink 0.1.2-2
libnettle 3.1.1-1
libopenssl 1.0.2.d-1
libp11-kit 0.23.1-1
libpcre 8.37-1
libpcre16 8.37-1
libpcre32 8.37-1
libpcrecpp 8.37-1
libpcreposix 8.37-1
libreadline 6.3.008-5
libsasl 2.1.26-7
libserf 1.3.8-1
libsqlite 3.8.8.2-1
libssh2 1.6.0-1
libtasn1 4.7-1
libutil-linux 2.26.2-1
libxml2 2.9.2-2
lndir 1.0.3-1
m4 1.4.17-4
make 4.1-4
mingw-w64-x86_64-binutils 2.25.1-1
mingw-w64-x86_64-bzip2 1.0.6-4
mingw-w64-x86_64-crt-git 5.0.0.4573.628fdbf-1
mingw-w64-x86_64-gcc 5.2.0-3
mingw-w64-x86_64-gcc-libs 5.2.0-3
mingw-w64-x86_64-gmp 6.0.0-3
mingw-w64-x86_64-headers-git 5.0.0.4575.ada0f35-1
mingw-w64-x86_64-isl 0.14.1-2
mingw-w64-x86_64-libiconv 1.14-5
mingw-w64-x86_64-libwinpthread-git 5.0.0.4573.628fdbf-1
mingw-w64-x86_64-mpc 1.0.3-2
mingw-w64-x86_64-mpfr 3.1.3.p0-2
mingw-w64-x86_64-windows-default-manifest 6.4-2
mingw-w64-x86_64-winpthreads-git 5.0.0.4573.628fdbf-1
mingw-w64-x86_64-zlib 1.2.8-9
mintty 1~2.1.5-1
mpfr 3.1.3.p0-1
msys2-keyring r9.397a52e-1
msys2-runtime 2.2.1.16655.6ecd782-2
ncurses 6.0.20150627-2
openssl 1.0.2.d-1
p11-kit 0.23.1-1
pacman 4.2.1.6198.439d376-1
pacman-mirrors 20150722-2
pax-git 20140703.2.1.g469552a-1
pcre 8.37-1
pkgfile 15-1
rebase 4.4.1-6
repman-git r23.87bf865-1
sed 4.2.2-2
subversion 1.9.1-1
tftp-hpa 5.2-1
time 1.7-1
tzcode 2015.e-1
util-linux 2.26.2-1
vim 7.4.872-2
which 2.21-2
xz 5.2.1-1
zlib 1.2.8-3


--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Building GCC on mingw-w64

2015-10-03 Thread niXman

FX 2015-10-04 00:57:
> Hi everyone,

Hi,

> Am I missing something?

Please read:
https://github.com/niXman/mingw-builds


-- 
Regards, niXman
___
Dual-target(32 & 64-bit) MinGW-W64 compilers for 32 and 64-bit Windows:
http://sourceforge.net/projects/mingw-w64/

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Building GCC on mingw-w64

2015-10-03 Thread FX

> MSYS2 distributes the gcc fortran package based on mingw-w64 (see the
> output of pacman -Ss fortran). You can inspect how it is built by
> consulting its PKGBUILD recipe. It is here, along with the necessary
> patches: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gcc

Thanks for the pointer. It’s sad that mingw has regressed, when GCC trunk used 
to build perfectly with no patch and configure options.

I’m trying now to force the build triplet to x86_64-w64-mingw32, rather than 
the detected value (x86_64-pc-mingw64).
So I have another question: which is the expected/canonical build triplet? 

FX
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Building GCC on mingw-w64

2015-10-03 Thread Ray Donnelly

On Sat, Oct 3, 2015 at 11:46 PM, FX  wrote:
>> MSYS2 distributes the gcc fortran package based on mingw-w64 (see the
>> output of pacman -Ss fortran). You can inspect how it is built by
>> consulting its PKGBUILD recipe. It is here, along with the necessary
>> patches: https://github.com/Alexpux/MINGW-packages/tree/master/mingw-w64-gcc
>
> Thanks for the pointer. It’s sad that mingw has regressed, when GCC trunk 
> used to build perfectly with no patch and configure options.
>
> I’m trying now to force the build triplet to x86_64-w64-mingw32, rather than 
> the detected value (x86_64-pc-mingw64).
> So I have another question: which is the expected/canonical build triplet?

x86_64-w64-mingw32 and i686-w64-mingw32 are the correct ones. "pc" is
for old mingw.org AFAIK.

>
> FX
> --
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Building GCC with --enable-libstdcxx-debug

2015-09-20 Thread Paulo Caetano

Hello.

I've finished a build with --enable-libstdcxx-debug, and this time I've
checked both the build tree and the install tree.

This is what I found on the build tree.
$ find . -name libstdc*.dll -exec ls -l {} \;
15,102,643 Sep 17 08:49
./prev-x86_64-w64-mingw32/libstdc++-v3/src/.libs/libstdc++-6.dll
16,678,882 Sep 17 08:50
./prev-x86_64-w64-mingw32/libstdc++-v3/src/debug/.libs/libstdc++-6.dll
15,102,643 Sep 17 08:26
./stage1-x86_64-w64-mingw32/libstdc++-v3/src/.libs/libstdc++-6.dll
16,678,882 Sep 17 08:27
./stage1-x86_64-w64-mingw32/libstdc++-v3/src/debug/.libs/libstdc++-6.dll
15,102,643 Sep 17 09:08
./x86_64-w64-mingw32/libstdc++-v3/src/.libs/libstdc++-6.dll
16,678,882 Sep 17 09:08
./x86_64-w64-mingw32/libstdc++-v3/src/debug/.libs/libstdc++-6.dll

So, both versions of the DLL are being built. One is the optimized version
(the size is identical to the DLL built when configured with
--disable-libstdcxx-debug). The other must be the debug version.

This is on the install tree created by make install. The installed DLL is,
indeed, the debug one, unlike what happens on Linux.
$ find . -name libstdc*.dll -exec ls -l {} \;
16,678,882 Sep 17 09:16 ./gcc/bin/libstdc++-6.dll

I don't think the hypothesis put forward by koala01 is the cause of the
problem, and I'll explain why.

This is when the optimized DLL is installed:
make[5]: Entering directory
'/home/TestUser/source/gcc/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3/src'
...
libtool: install:
  dlpath=`/bin/sh 2>&1 -c '. .libs/'libstdc++.la'i; echo
libstdc++-6.dll'`
libtool: install:

dldir=/opt/dbg_strip_default/gcc/lib/gcc/x86_64-w64-mingw32/5.2.0/`dirname
../../../../bin/libstdc++-6.dll`
libtool: install:
  test -d
/opt/dbg_strip_default/gcc/lib/gcc/x86_64-w64-mingw32/5.2.0/../../../../bin
|| mkdir -p
/opt/dbg_strip_default/gcc/lib/gcc/x86_64-w64-mingw32/5.2.0/../../../../bin
libtool: install:
  /usr/bin/install -c .libs/libstdc++-6.dll
/opt/dbg_strip_default/gcc/lib/gcc/x86_64-w64-mingw32/5.2.0/../../../../bin/libstdc++-6.dll
libtool: install:
  chmod a+x
/opt/dbg_strip_default/gcc/lib/gcc/x86_64-w64-mingw32/5.2.0/../../../../bin/libstdc++-6.dll
libtool: install:
  if test -n '' && test -n 'strip --strip-unneeded'; then
eval 'strip --strip-unneeded
/opt/dbg_strip_default/gcc/lib/gcc/x86_64-w64-mingw32/5.2.0/../../../../bin/libstdc++-6.dll'
|| exit 0;
  fi

It's installing the DLL from x86_64-w64-mingw32/libstdc++-v3/src (i.e., the
optimized DLL) to
/opt/dbg_strip_default/gcc/lib/gcc/x86_64-w64-mingw32/5.2.0/../../../../bin/libstdc++-6.dll,
i.e., /opt/dbg_strip_default/gcc/bin/libstdc++-6.dll, as expected.

And, then, we get this:
make[8]: Entering directory
'/home/TestUser/source/gcc/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3/src/debug'
...
libtool: install:
  dlpath=`/bin/sh 2>&1 -c '. .libs/'libstdc++.la'i; echo
libstdc++-6.dll'`
libtool: install:

dldir=/opt/dbg_strip_default/gcc/lib/gcc/x86_64-w64-mingw32/5.2.0/debug/`dirname
../../../../../bin/libstdc++-6.dll`
libtool: install:
  test -d
/opt/dbg_strip_default/gcc/lib/gcc/x86_64-w64-mingw32/5.2.0/debug/../../../../../bin
|| mkdir -p
/opt/dbg_strip_default/gcc/lib/gcc/x86_64-w64-mingw32/5.2.0/debug/../../../../../bin
libtool: install:
  /usr/bin/install -c .libs/libstdc++-6.dll
/opt/dbg_strip_default/gcc/lib/gcc/x86_64-w64-mingw32/5.2.0/debug/../../../../../bin/libstdc++-6.dll
libtool: install:
  chmod a+x
/opt/dbg_strip_default/gcc/lib/gcc/x86_64-w64-mingw32/5.2.0/debug/../../../../../bin/libstdc++-6.dll
libtool: install:
  if test -n '' && test -n 'strip --strip-unneeded'; then
eval 'strip --strip-unneeded
/opt/dbg_strip_default/gcc/lib/gcc/x86_64-w64-mingw32/5.2.0/debug/../../../../../bin/libstdc++-6.dll'
|| exit 0;
  fi

It's overwriting the optimized DLL with the debug DLL, instead of
installing it on the debug directory.

BTW, immediately afterwards, we get this, correctly installing the static
lib on the debug directory:
libtool: install: /usr/bin/install -c .libs/libstdc++.lai
/opt/dbg_strip_default/gcc/lib/gcc/x86_64-w64-mingw32/5.2.0/debug/libstdc++.la
libtool: install: /usr/bin/install -c .libs/libstdc++.a
/opt/dbg_strip_default/gcc/lib/gcc/x86_64-w64-mingw32/5.2.0/debug/libstdc++.a
libtool: install: chmod 644
/opt/dbg_strip_default/gcc/lib/gcc/x86_64-w64-mingw32/5.2.0/debug/libstdc++.a
libtool: install: ranlib
/opt/dbg_strip_default/gcc/lib/gcc/x86_64-w64-mingw32/5.2.0/debug/libstdc++.a
libtool: install: warning: remember to run `libtool --finish
/gcc/lib/gcc/x86_64-w64-mingw32/5.2.0/debug'

Getting back to the installation of the debug DLL, I'm assuming it comes
from the build tree, from ./x86_64-w64-mingw32/libstdc++-v3/libtool:
postinstall_cmds="base_file=\\\`basename \\\${file}\\\`~
  dlpath=\\\`\$SHELL 2>&1 -c '. \$dir/'\\\${base_file}'i; echo
\\\$dlname'\\\`~
  dldir=\$destdir/\\\`dirname \\\$dlpath\\\`~
  test -d \\\$dldir || mkdir -p \\\$dldir~
  \$install_prog

Re: [Mingw-w64-public] Building GCC with --enable-libstdcxx-debug

2015-09-15 Thread Paulo Caetano

Hello.

First of all, sorry for the late reply. I ran into a bit of a problem last
week, and learned the hard way that having backups is not enough, you need
to test them every now and then.

Anyway, I've just checked the build tree for the last build I performed
(with --enable-libstdcxx-debug), and you are correct, there are two
different versions of libstdc++.dll

14484098 ./prev-x86_64-w64-mingw32/libstdc++-v3/src/.libs/libstdc++-6.dll
16576791
./prev-x86_64-w64-mingw32/libstdc++-v3/src/debug/.libs/libstdc++-6.dll
14484098 ./stage1-x86_64-w64-mingw32/libstdc++-v3/src/.libs/libstdc++-6.dll
16576791
./stage1-x86_64-w64-mingw32/libstdc++-v3/src/debug/.libs/libstdc++-6.dll
14484098 ./x86_64-w64-mingw32/libstdc++-v3/src/.libs/libstdc++-6.dll
16576791 ./x86_64-w64-mingw32/libstdc++-v3/src/debug/.libs/libstdc++-6.dll

Unfortunately, I've lost the install trees of my previous builds, but I'll
be running them again in the next days. I'll post back here, when I have
more info.

Thanks, again, for your help.
---
Paulo Caetano
http://cidebycide.blogspot.pt/


On Tue, Sep 8, 2015 at 4:03 PM, koala01  wrote:

> Le 07/09/2015 23:23, Paulo Caetano a écrit :
> > Hello.
> >
> > I've been experimenting building GCC with --enable-libstdcxx-debug,
> > both on Linux and MSYS2, and there's one thing I'm not sure of and I
> > wonder if you could help me understand it.
> >
> > GCC docs say that configuring GCC with --enable-libstdcxx-debug will
> > build debug libraries "in addition to what is normally built", i.e.,
> > in addition to the optimized libraries.
> >
> > I've tested this on Linux (Fedora 22, gcc 5.2.0), and it works as
> > expected. It builds two versions of libstdc++.a and a libstdc++.so
> > (libstdc++.so.6.0.21), which are installed in
> > /lib/gcc/x86_64-redhat-linux/5.2.0 (optimized version, or
> > "what is normally built"), and in
> > /lib/gcc/x86_64-redhat-linux/5.2.0/debug (debug version).
> >
> > However, using --enable-libstdcxx-debug on MSYS2 gives me a different
> > result. I got a single libstdc++.dll, in /bin, and two
> > versions of libstdc++.a, one in
> > /lib/gcc/x86_64-w64-mingw32/5.2.0 and another in
> > /lib/gcc/x86_64-w64-mingw32/5.2.0/debug.
> >
> > My first hypothesis was that --enable-libstdcxx-debug on MSYS2 was not
> > creating the debug DLL (which I expected to find in
> > /lib/gcc/x86_64-w64-mingw32/5.2.0/debug). However, when I
> > compared the versions of libstdc++.dll created using
> > --enable-libstdcxx-debug vs. --disable-libstdcxx-debug, I noticed they
> > were different.
> >
> > So, my conclusion, so far, is that --disable-libstdcxx-debug acts
> > similar on Linux and MSYS2, and that --enable-libstdcxx-debug, on
> > MSYS2, has the following behaviour:
> > - Does not create the libstdc++.dll that is "normally built", i.e.,
> > the optimized version.
> > - Creates the debug version of libstdc++.dll and installs it in
> > /bin.
> > - Creates the debug version of libstdc++.a and installs it in
> > /lib/gcc/x86_64-w64-mingw32/5.2.0/debug.
> > - Created the libstdc++.a that is "normally built", i.e., the
> > optimized version, and installs it in
> > lib/gcc/x86_64-w64-mingw32/5.2.0. 
> >
> > Is my reasoning correct, or am I missing something?
> >
> > Thanks for your help.
> > ---
> > Paulo Caetano
> > http://cidebycide.blogspot.pt/
> Hello,
>
> If i'm right (and i'm not sure to be :P) the problem comes from the Gcc
> install script which doesn't make special directories for dll.
>
> I've experienced this problem in many occasions when compiling a
> multilib version of Gcc (but with older Gcc versions), and the better
> way i've found now is to manually create a separate directory for one
> kind of dlls (will say : 32bits version ... should be debug version in
> your special case) and to manually copy each dll to them correct place.
>
> Hope it helps ;)
>
>
> --
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Building GCC with --enable-libstdcxx-debug

2015-09-08 Thread koala01

Le 07/09/2015 23:23, Paulo Caetano a écrit :
> Hello.
>
> I've been experimenting building GCC with --enable-libstdcxx-debug, 
> both on Linux and MSYS2, and there's one thing I'm not sure of and I 
> wonder if you could help me understand it.
>
> GCC docs say that configuring GCC with --enable-libstdcxx-debug will 
> build debug libraries "in addition to what is normally built", i.e., 
> in addition to the optimized libraries.
>
> I've tested this on Linux (Fedora 22, gcc 5.2.0), and it works as 
> expected. It builds two versions of libstdc++.a and a libstdc++.so 
> (libstdc++.so.6.0.21), which are installed in 
> /lib/gcc/x86_64-redhat-linux/5.2.0 (optimized version, or 
> "what is normally built"), and in 
> /lib/gcc/x86_64-redhat-linux/5.2.0/debug (debug version).
>
> However, using --enable-libstdcxx-debug on MSYS2 gives me a different 
> result. I got a single libstdc++.dll, in /bin, and two 
> versions of libstdc++.a, one in 
> /lib/gcc/x86_64-w64-mingw32/5.2.0 and another in 
> /lib/gcc/x86_64-w64-mingw32/5.2.0/debug.
>
> My first hypothesis was that --enable-libstdcxx-debug on MSYS2 was not 
> creating the debug DLL (which I expected to find in 
> /lib/gcc/x86_64-w64-mingw32/5.2.0/debug). However, when I 
> compared the versions of libstdc++.dll created using 
> --enable-libstdcxx-debug vs. --disable-libstdcxx-debug, I noticed they 
> were different.
>
> So, my conclusion, so far, is that --disable-libstdcxx-debug acts 
> similar on Linux and MSYS2, and that --enable-libstdcxx-debug, on 
> MSYS2, has the following behaviour:
> - Does not create the libstdc++.dll that is "normally built", i.e., 
> the optimized version.
> - Creates the debug version of libstdc++.dll and installs it in 
> /bin.
> - Creates the debug version of libstdc++.a and installs it in 
> /lib/gcc/x86_64-w64-mingw32/5.2.0/debug.
> - Created the libstdc++.a that is "normally built", i.e., the 
> optimized version, and installs it in 
> lib/gcc/x86_64-w64-mingw32/5.2.0. 
>
> Is my reasoning correct, or am I missing something?
>
> Thanks for your help.
> ---
> Paulo Caetano
> http://cidebycide.blogspot.pt/
Hello,

If i'm right (and i'm not sure to be :P) the problem comes from the Gcc 
install script which doesn't make special directories for dll.

I've experienced this problem in many occasions when compiling a 
multilib version of Gcc (but with older Gcc versions), and the better 
way i've found now is to manually create a separate directory for one 
kind of dlls (will say : 32bits version ... should be debug version in 
your special case) and to manually copy each dll to them correct place.

Hope it helps ;)

--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Building GCC with --enable-libstdcxx-debug

2015-09-07 Thread Paulo Caetano

Hello.

I've been experimenting building GCC with --enable-libstdcxx-debug, both on
Linux and MSYS2, and there's one thing I'm not sure of and I wonder if you
could help me understand it.

GCC docs say that configuring GCC with --enable-libstdcxx-debug will build
debug libraries "in addition to what is normally built", i.e., in addition
to the optimized libraries.

I've tested this on Linux (Fedora 22, gcc 5.2.0), and it works as expected.
It builds two versions of libstdc++.a and a libstdc++.so
(libstdc++.so.6.0.21), which are installed in
/lib/gcc/x86_64-redhat-linux/5.2.0 (optimized version, or "what is
normally built"), and in /lib/gcc/x86_64-redhat-linux/5.2.0/debug
(debug version).

However, using --enable-libstdcxx-debug on MSYS2 gives me a different
result. I got a single libstdc++.dll, in /bin, and two versions of
libstdc++.a, one in /lib/gcc/x86_64-w64-mingw32/5.2.0 and another
in /lib/gcc/x86_64-w64-mingw32/5.2.0/debug.

My first hypothesis was that --enable-libstdcxx-debug on MSYS2 was not
creating the debug DLL (which I expected to find in
/lib/gcc/x86_64-w64-mingw32/5.2.0/debug). However, when I compared
the versions of libstdc++.dll created using --enable-libstdcxx-debug vs.
--disable-libstdcxx-debug, I noticed they were different.

So, my conclusion, so far, is that --disable-libstdcxx-debug acts similar
on Linux and MSYS2, and that --enable-libstdcxx-debug, on MSYS2, has the
following behaviour:
- Does not create the libstdc++.dll that is "normally built", i.e., the
optimized version.
- Creates the debug version of libstdc++.dll and installs it in
/bin.
- Creates the debug version of libstdc++.a and installs it in
/lib/gcc/x86_64-w64-mingw32/5.2.0/debug.
- Created the libstdc++.a that is "normally built", i.e., the optimized
version, and installs it in lib/gcc/x86_64-w64-mingw32/5.2.0.


Is my reasoning correct, or am I missing something?

Thanks for your help.
---
Paulo Caetano
http://cidebycide.blogspot.pt/
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Building GCC 5.1 with --enable-host-shared --enable-languages=jit --disable-bootstrap

2015-04-25 Thread Kai Tietz

Hi,

I have not tried to build jit option for windows right now.
Nevertheless you shouldn't remove the c-languages from bootstrap as
modern gcc requires at least c++ for doing a full bootstrap.
Additionally I would recomment to specify explicit --disable-multilib
option, as this could otherwise easily lead to unwanted problems, too.

There are instructions on using mingw-w64.  Please visit either our
Wiki, or you can visit us on our irc-channel at #mingw-w64 on
irc.oftc.net

Regards,
Kai

2015-04-24 23:58 GMT+02:00 Hayden Livingston halivings...@gmail.com:
 Hey folks,

 I was wondering has anybody tried building GCC 5.1 with the new JIT
 language support.

 I tried and it failed, but I'm admittedly a noob in buiding GCC on Windows.

 Are there instructions using MingW-w64?

 I've downloaded everything, but I keep getting make errors like
 (libiberty.a is needed, but couldn't make it). I also don't know where
 to find the logs.

 Any help appreciated.

 --
 One dashboard for servers and applications across Physical-Virtual-Cloud
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Building GCC 5.1 with --enable-host-shared --enable-languages=jit --disable-bootstrap

2015-04-24 Thread Hayden Livingston

Hey folks,

I was wondering has anybody tried building GCC 5.1 with the new JIT
language support.

I tried and it failed, but I'm admittedly a noob in buiding GCC on Windows.

Are there instructions using MingW-w64?

I've downloaded everything, but I keep getting make errors like
(libiberty.a is needed, but couldn't make it). I also don't know where
to find the logs.

Any help appreciated.

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Building GCC with crazy host-build-target

2014-01-10 Thread JonY

On 1/10/2014 17:21, Ruben Van Boxem wrote:
 Hi,
 
 I'm attempting to build GCC with the following triplets:
 checking build system type... x86_64-unknown-linux-gnu
 checking host system type... i686-unknown-linux-gnu
 checking target system type... i686-w64-mingw32
 

Above is OK.

 I configured just like the normal version, adding
 CC='gcc -m32' CXX='g++ -m32' AR=ar

Don't do that and do not argue about it, especially in a Canadian cross.




signature.asc
Description: OpenPGP digital signature
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Building GCC with crazy host-build-target

2014-01-10 Thread Ruben Van Boxem

2014/1/10 JonY jo...@users.sourceforge.net

 On 1/10/2014 17:21, Ruben Van Boxem wrote:
  Hi,
 
  I'm attempting to build GCC with the following triplets:
  checking build system type... x86_64-unknown-linux-gnu
  checking host system type... i686-unknown-linux-gnu
  checking target system type... i686-w64-mingw32
 

 Above is OK.

  I configured just like the normal version, adding
  CC='gcc -m32' CXX='g++ -m32' AR=ar

 Don't do that and do not argue about it, especially in a Canadian cross.


OK, I won't argue. It was a hack anyways. Instead, I shall ask a question
:-)

How do I use a GCC multilib Linux toolchain to build a Canadian Cross
compiler with the multilib's alternative host (see above)? I'd like to not
have to install a 32-bit linux OS when my GCC can very will build 32-bit
binaries.

Thanks!

Ruben





 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.

 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Building GCC with crazy host-build-target

2014-01-10 Thread JonY

On 1/10/2014 18:46, Ruben Van Boxem wrote:
 2014/1/10 JonY jo...@users.sourceforge.net
 
 On 1/10/2014 17:21, Ruben Van Boxem wrote:
 Hi,

 I'm attempting to build GCC with the following triplets:
 checking build system type... x86_64-unknown-linux-gnu
 checking host system type... i686-unknown-linux-gnu
 checking target system type... i686-w64-mingw32


 Above is OK.

 I configured just like the normal version, adding
 CC='gcc -m32' CXX='g++ -m32' AR=ar

 Don't do that and do not argue about it, especially in a Canadian cross.

 
 OK, I won't argue. It was a hack anyways. Instead, I shall ask a question
 :-)
 
 How do I use a GCC multilib Linux toolchain to build a Canadian Cross
 compiler with the multilib's alternative host (see above)? I'd like to not
 have to install a 32-bit linux OS when my GCC can very will build 32-bit
 binaries.

You write thin i686-* wrappers, setting CC/CXX is going to muck up a lot
more than the first layer builds for the host machine since it will
apply to EVERYTHING.

Alternatively, don't use multilib if you can. They're fun additions but
autotools doesn't handle them atm without ugly hacks.




signature.asc
Description: OpenPGP digital signature
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] building GCC with -flto

2013-03-23 Thread Ruben Van Boxem

Hi,

Since people said it was possible, I tried. I also failed.

I configured GCC 4.8.0 with [CCX,C,LD]FLAGS_FOR_TARGET=-flto, and got
this error when building libgcc:
ln -s -f libgcc.map libgcc.map.def  if [ ! -d ./shlib ]; then mkdir
./shlib; else true; fi 
/home/ruben/mingw-w64/linux64mingw32/gcc/./gcc/xgcc
-B/home/ruben/mingw-w64/linux64mingw32/gcc/./gcc/
-L/home/ruben/mingw-w64/linux64mingw32/mingw32/i686-w64-mingw32/lib
-L/home/ruben/mingw-w64/linux64mingw32/mingw32/mingw/lib -isystem
/home/ruben/mingw-w64/linux64mingw32/mingw32/i686-w64-mingw32/include
-isystem /home/ruben/mingw-w64/linux64mingw32/mingw32/mingw/include
-B/home/ruben/mingw-w64/linux64mingw32/mingw32/i686-w64-mingw32/bin/
-B/home/ruben/mingw-w64/linux64mingw32/mingw32/i686-w64-mingw32/lib/
-isystem
/home/ruben/mingw-w64/linux64mingw32/mingw32/i686-w64-mingw32/include
-isystem
/home/ruben/mingw-w64/linux64mingw32/mingw32/i686-w64-mingw32/sys-include
-O2 -I/home/ruben/mingw-w64/src/gcc/libgcc/../winsup/w32api/include -O2
-march=nocona -mtune=core2 -flto -fgraphite-identity -floop-interchange
-floop-block -floop-parallelize-all -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE
-W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition  -isystem ./include   -g
-DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector   -shared
-nodefaultlibs libgcc.map.def -Wl,--out-implib,./shlib/libgcc_s.a.tmp -o
./shlib/libgcc_s_sjlj-1.dll.tmp -O2 -march=nocona -mtune=core2 -flto
-fgraphite-identity -floop-interchange -floop-block -floop-parallelize-all
-B./ _chkstk_s.o _chkstk_ms_s.o _muldi3_s.o _negdi2_s.o _lshrdi3_s.o
_ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o
_trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o
_addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o
_negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o
_clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o
_popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o
_powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o
_mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o
_bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o
_fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o
_fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o
_floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o
_floatundixf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o
_udiv_w_sdiv_s.o _udivmoddi4_s.o gthr-win32_s.o cpuinfo_s.o tf-signs_s.o
sfp-exceptions_s.o addtf3_s.o divtf3_s.o eqtf2_s.o getf2_s.o letf2_s.o
multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o
floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o
floatunditf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o
trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o enable-execute-stack_s.o
unwind-dw2_s.o unwind-dw2-fde_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o
libgcc.a  -lmingwthrd -lmingw32 -lmingwex -lmoldname -lmsvcrt -ladvapi32
-lshell32 -luser32 -lkernel32  if [ -f ./shlib/libgcc_s_sjlj-1.dll ];
then mv -f ./shlib/libgcc_s_sjlj-1.dll ./shlib/libgcc_s_sjlj-1.dll.backup;
else true; fi  mv ./shlib/libgcc_s_sjlj-1.dll.tmp
./shlib/libgcc_s_sjlj-1.dll  mv ./shlib/libgcc_s.a.tmp ./shlib/libgcc_s.a
/home/ruben/mingw-w64/src/gcc/libgcc/libgcc2.c:1934:1: error: '__divtc3'
has already been defined
 CONCAT3(__div,MODE,3) (MTYPE a, MTYPE b, MTYPE c, MTYPE d)
 ^
/home/ruben/mingw-w64/src/gcc/libgcc/libgcc2.c:1934:1: note: previously
defined here
 CONCAT3(__div,MODE,3) (MTYPE a, MTYPE b, MTYPE c, MTYPE d)
 ^
/home/ruben/mingw-w64/src/gcc/libgcc/libgcc2.c:1934:1: error: '__divxc3'
has already been defined
 CONCAT3(__div,MODE,3) (MTYPE a, MTYPE b, MTYPE c, MTYPE d)
 ^
/home/ruben/mingw-w64/src/gcc/libgcc/libgcc2.c:1934:1: note: previously
defined here
 CONCAT3(__div,MODE,3) (MTYPE a, MTYPE b, MTYPE c, MTYPE d)
 ^
/home/ruben/mingw-w64/src/gcc/libgcc/libgcc2.c:1934:1: error: '__divdc3'
has already been defined
 CONCAT3(__div,MODE,3) (MTYPE a, MTYPE b, MTYPE c, MTYPE d)
 ^
/home/ruben/mingw-w64/src/gcc/libgcc/libgcc2.c:1934:1: note: previously
defined here
 CONCAT3(__div,MODE,3) (MTYPE a, MTYPE b, MTYPE c, MTYPE d)
 ^
/home/ruben/mingw-w64/src/gcc/libgcc/libgcc2.c:1934:1: error: '__divsc3'
has already been defined
 CONCAT3(__div,MODE,3) (MTYPE a, MTYPE b, MTYPE c, MTYPE d)
 ^
/home/ruben/mingw-w64/src/gcc/libgcc/libgcc2.c:1934:1: note: previously
defined here
 CONCAT3(__div,MODE,3) (MTYPE a, MTYPE b, MTYPE c, MTYPE d)
 ^
/home/ruben/mingw-w64/src/gcc/libgcc/libgcc2.c:1864:1: error: '__multc3'
has already been defined
 CONCAT3(__mul,MODE,3) (MTYPE a, MTYPE b, MTYPE c, MTYPE d)
 ^
/home/ruben/mingw-w64/src/gcc/libgcc/libgcc2.c:1864:1: note: previously
defined here
 CONCAT3(__mul,MODE,3) (MTYPE a, MTYPE b, MTYPE c, MTYPE d)
 ^
/home/ruben/mingw-w64/src/gcc/libgcc/libgcc2.c:1864:1: error: '__mulxc3'
has already been defined

Re: [Mingw-w64-public] Building GCC with my scripts under MSYS

2011-07-10 Thread PcX


于 2011/7/10 20:52, Earnie 写道:

  I didn't think it was possible to build in the
source directory for the GCC package, when did it change?  It is also
advised to build in a separate build directory instead of the source
directory so if this is reproducibly true then a bug report needs to be
open for MSYS giving the details of how to reproduce it.

Yea, I agree with your point. But I only say *sometimes on msys*...
I don't know why this come out, as when I use Linux, I don't meet the 
kind of question...


--
Best Regards,
PcX

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Building GCC with my scripts under MSYS

2011-07-10 Thread Ruben Van Boxem

2011/7/10 PcX xunxun1...@gmail.com

  于 2011/7/10 20:52, Earnie 写道:

  I didn't think it was possible to build in the
 source directory for the GCC package, when did it change?  It is also
 advised to build in a separate build directory instead of the source
 directory so if this is reproducibly true then a bug report needs to be
 open for MSYS giving the details of how to reproduce it.

  Yea, I agree with your point. But I only say *sometimes on msys*...
 I don't know why this come out, as when I use Linux, I don't meet the kind
 of question...


I don't feel comfortable building in an unsupported fashion. I understand it
might work around the issue, but that shouldn't be necessary in the first
place.

Ruben
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Building GCC with my scripts under MSYS

2011-07-10 Thread Earnie

Ruben Van Boxem wrote:
 2011/7/10 Earnie ear...@users.sourceforge.net

 PcX wrote:
 于 2011/7/10 1:55, Ruben Van Boxem 写道:
 Which is very odd, because the file that does not exist,
 exists.

 Sometimes, on msys, if your source directory and build directory
 is different, the some file does not exit error will appear. I
 don't know this reason. So if I build gcc on msys, I will build
 in the source directory. For a long time, this method make the
 build stage easy.


 Hmm, why would that be.  I didn't think it was possible to build in
 the source directory for the GCC package, when did it change?  It
 is also advised to build in a separate build directory instead of
 the source directory so if this is reproducibly true then a bug
 report needs to be open for MSYS giving the details of how to
 reproduce it.


 I have submitted a bug report here:
 https://sourceforge.net/tracker/?func=detailatid=102435aid=3361858group_id=2435



with the exact steps I took to reproduce this problem last time. I
 understand the build scripts are a big unknown here, but they
 work fine on Linux and do what they should under proper Bash. I
 should try to run them under Cygwin just to check, but I'm not strong
 on Cygwin stuff. I'll update the report when I've tried that.


The difference with Cygwin is it doesn't convert the paths to give to a
native GCC which is where this is failing.  The path in the error
message is definitely a POSIX path and not a WINDOWS path.  Also with
Cygwin it is setup as a cross build so no paths need to be converted so
I'm guessing you'll find that it works.

Earnie

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Building GCC with my scripts under MSYS

2011-07-09 Thread Ruben Van Boxem

In an attempt to help all these people trying to build GCC toolchains (for
reasons still very mysterious to me), I attempted modifying them to build a
32-bit to 64-bit cross-compiler and tried running it on MSYS with my 32-bit
toolchain.

In the gcc-c stage, I get this error:

make[1]: Entering directory `/home/Ruben/mingw32cross64/gcc-c/gcc'
i686-w64-mingw32-gcc -c   -O2 -mtune=core2 -fomit-frame-pointer
-momit-leaf-frame-pointer -fgraphite-identity -floop-interchange
-floop-block -floop-parallelize-all -D__USE_MINGW_ACCESS -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -DNATIVE_CROSS  -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Wold-style-definition -Wc++-compat
-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/home/Ruben/src/gcc/gcc
-I/home/Ruben/src/gcc/gcc/build -I/home/Ruben/src/gcc/gcc/../include
-I/home/Ruben/src/gcc/gcc/../libcpp/include
-I/home/Ruben/mingw32cross64/libs/include
-I/home/Ruben/mingw32cross64/libs/include
-I/home/Ruben/mingw32cross64/libs/include
-I/home/Ruben/src/gcc/gcc/../libdecnumber
-I/home/Ruben/src/gcc/gcc/../libdecnumber/bid -I../libdecnumber
-I/home/Ruben/mingw32cross64/libs/include
-I/home/Ruben/mingw32cross64/libs/include -DCLOOG_INT_GMP -DCLOOG_ORG
-I/home/Ruben/mingw32cross64/libs/include \
-o build/genflags.o /home/Ruben/src/gcc/gcc/genflags.c
build/gengtype.exe  \
-S /home/Ruben/src/gcc/gcc -I gtyp-input.list -w
gtype.state
i686-w64-mingw32-gcc -c   -O2 -mtune=core2 -fomit-frame-pointer
-momit-leaf-frame-pointer -fgraphite-identity -floop-interchange
-floop-block -floop-parallelize-all -D__USE_MINGW_ACCESS -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -DNATIVE_CROSS  -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Wold-style-definition -Wc++-compat
-DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild -I/home/Ruben/src/gcc/gcc
-I/home/Ruben/src/gcc/gcc/build -I/home/Ruben/src/gcc/gcc/../include
-I/home/Ruben/src/gcc/gcc/../libcpp/include
-I/home/Ruben/mingw32cross64/libs/include
-I/home/Ruben/mingw32cross64/libs/include
-I/home/Ruben/mingw32cross64/libs/include
-I/home/Ruben/src/gcc/gcc/../libdecnumber
-I/home/Ruben/src/gcc/gcc/../libdecnumber/bid -I../libdecnumber
-I/home/Ruben/mingw32cross64/libs/include
-I/home/Ruben/mingw32cross64/libs/include -DCLOOG_INT_GMP -DCLOOG_ORG
-I/home/Ruben/mingw32cross64/libs/include \
-o build/read-rtl.o /home/Ruben/src/gcc/gcc/read-rtl.c
/home/Ruben/src/gcc/gcc/../libcpp/include/line-map.h: No such file or
directory
make[1]: *** [s-gtype] Error 1
make[1]: *** Waiting for unfinished jobs
make[1]: Leaving directory `/home/Ruben/mingw32cross64/gcc-c/gcc'

Which is very odd, because the file that does not exist, exists. I remember
this is the reason I moved to a Linux cross-compile build process. Back
then, I thought it was a user error or a bad setup, but apparently it also
happens in a streamlined build system like mine ;-) I set these options:
export HOST=i686-w64-mingw32
export TARGET=x86_64-w64-mingw32
export BUILD=i686-w64-mingw32
export CRT_MULTILIB='--enable-lib64 --disable-lib32'

Which should build a nice 32-bit toolchain that produces 64-bit binaries. I
used my 4.6.2 source package for this.

Any thoughts are very much appreciated, because I'm pretty clueless...

Ruben
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Building GCC with my scripts under MSYS

2011-07-09 Thread Earnie

JonY wrote:
 On 7/10/2011 01:55, Ruben Van Boxem wrote:
 In an attempt to help all these people trying to build GCC
 toolchains (for reasons still very mysterious to me), I attempted
 modifying them to build a 32-bit to 64-bit cross-compiler and tried
 running it on MSYS with my 32-bit toolchain.

 In the gcc-c stage, I get this error:

 make[1]: Entering directory `/home/Ruben/mingw32cross64/gcc-c/gcc'
 i686-w64-mingw32-gcc -c   -O2 -mtune=core2 -fomit-frame-pointer
 -momit-leaf-frame-pointer -fgraphite-identity -floop-interchange
 -floop-block -floop-parallelize-all -D__USE_MINGW_ACCESS -DIN_GCC
 -DCROSS_DIRECTORY_STRUCTURE -DNATIVE_CROSS  -W -Wall
 -Wwrite-strings -Wcast-qual -Wstrict-prototypes
 -Wmissing-prototypes -Wmissing-format-attribute -pedantic
 -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
 -Wold-style-definition -Wc++-compat -DHAVE_CONFIG_H
 -DGENERATOR_FILE -I. -Ibuild -I/home/Ruben/src/gcc/gcc
 -I/home/Ruben/src/gcc/gcc/build
 -I/home/Ruben/src/gcc/gcc/../include
 -I/home/Ruben/src/gcc/gcc/../libcpp/include
 -I/home/Ruben/mingw32cross64/libs/include
 -I/home/Ruben/mingw32cross64/libs/include
 -I/home/Ruben/mingw32cross64/libs/include
 -I/home/Ruben/src/gcc/gcc/../libdecnumber
 -I/home/Ruben/src/gcc/gcc/../libdecnumber/bid -I../libdecnumber
 -I/home/Ruben/mingw32cross64/libs/include
 -I/home/Ruben/mingw32cross64/libs/include -DCLOOG_INT_GMP
 -DCLOOG_ORG -I/home/Ruben/mingw32cross64/libs/include \ -o
 build/genflags.o /home/Ruben/src/gcc/gcc/genflags.c
 build/gengtype.exe  \ -S /home/Ruben/src/gcc/gcc -I gtyp-input.list
 -w gtype.state i686-w64-mingw32-gcc -c   -O2 -mtune=core2
 -fomit-frame-pointer -momit-leaf-frame-pointer -fgraphite-identity
 -floop-interchange -floop-block -floop-parallelize-all
 -D__USE_MINGW_ACCESS -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE
 -DNATIVE_CROSS  -W -Wall -Wwrite-strings -Wcast-qual
 -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
 -pedantic -Wno-long-long -Wno-variadic-macros
 -Wno-overlength-strings -Wold-style-definition -Wc++-compat
 -DHAVE_CONFIG_H -DGENERATOR_FILE -I. -Ibuild
 -I/home/Ruben/src/gcc/gcc -I/home/Ruben/src/gcc/gcc/build
 -I/home/Ruben/src/gcc/gcc/../include
 -I/home/Ruben/src/gcc/gcc/../libcpp/include
 -I/home/Ruben/mingw32cross64/libs/include
 -I/home/Ruben/mingw32cross64/libs/include
 -I/home/Ruben/mingw32cross64/libs/include
 -I/home/Ruben/src/gcc/gcc/../libdecnumber
 -I/home/Ruben/src/gcc/gcc/../libdecnumber/bid -I../libdecnumber
 -I/home/Ruben/mingw32cross64/libs/include
 -I/home/Ruben/mingw32cross64/libs/include -DCLOOG_INT_GMP
 -DCLOOG_ORG -I/home/Ruben/mingw32cross64/libs/include \ -o
 build/read-rtl.o /home/Ruben/src/gcc/gcc/read-rtl.c
 /home/Ruben/src/gcc/gcc/../libcpp/include/line-map.h: No such file
 or directory make[1]: *** [s-gtype] Error 1 make[1]: *** Waiting
 for unfinished jobs make[1]: Leaving directory
 `/home/Ruben/mingw32cross64/gcc-c/gcc'

 Which is very odd, because the file that does not exist, exists. I
 remember this is the reason I moved to a Linux cross-compile build
 process. Back then, I thought it was a user error or a bad setup,
 but apparently it also happens in a streamlined build system like
 mine ;-) I set these options: export HOST=i686-w64-mingw32 export
 TARGET=x86_64-w64-mingw32 export BUILD=i686-w64-mingw32 export
 CRT_MULTILIB='--enable-lib64 --disable-lib32'

 Which should build a nice 32-bit toolchain that produces 64-bit
 binaries. I used my 4.6.2 source package for this.

 Any thoughts are very much appreciated, because I'm pretty
 clueless...

 Ruben

 Hi,

 have you tried using a released version? Just to make sure it isn't
 a transient bug in the svn repo versions.

 Other than thant, I have little idea whats going on, maybe you can
 post your full gcc configure line too.

My opinion is that it is a race condition between MSYS, GCC, the OS and
disk controllers.  There is a lot of manipulation going on with the -I
strings within MSYS and something could have gone awry. Does it continue
to give the same result if you start the make process again?

Hmm, the error is
``/home/Ruben/src/gcc/gcc/../libcpp/include/line-map.h: No such file or
directory'' indicating to me that PATH didn't get modified by MSYS
before passing it on to gcc or something is using the string path as is
and generating source with the full path to the header file.  I assume
that src/gcc/libcpp/include/line-map.h is already a part of the source
bundle.

Earnie

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net

Re: [Mingw-w64-public] Building GCC with my scripts under MSYS

2011-07-09 Thread PcX

于 2011/7/10 1:55, Ruben Van Boxem 写道:
 Which is very odd, because the file that does not exist, exists.

Sometimes, on msys, if your source directory and build directory is 
different, the some file does not exit error will appear. I don't know 
this reason.
So if I build gcc on msys, I will build in the source directory.
For a long time, this method make the build stage easy.

Using the same directory, I have built gcc 4.5-4.6 edition successfully. 
[http://code.google.com/p/pcxprj/downloads/list]

-- 
Best Regards,
PcX


--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] building gcc

2011-07-03 Thread Bj Raz

On Sun, Jul 3, 2011 at 6:06 AM, JonY jo...@users.sourceforge.net wrote:

On 7/3/2011 12:10, Bj Raz wrote:
I've been working on cross compiler for building w64 binaries. I just
wanted to see if I could do it :P
I'm following the directions from Linux From Scratch (modifying them as
needed).
So I've built gcc with c++ support and I have the errors:

See mingw-w64-docs for help on building. A lot of LFS doesn't apply to
mingw-w64.

/tools/x86_64-w64-mingw32/bin/ld cannot find dllcrt2.o: No such file
or directory
/tools/x86_64-w64-mingw32/bin/ld cannot find crtbegin.o: No such file
or directory
/tools/x86_64-w64-mingw32/bin/ld cannot find crtend.o: No such file or
directory
collect2: ld returned 1 exit status
make[2]: *** [libgcc_s.dll] Error 1
make[1]: *** [all-target-libgcc] Error 2
make: *** [all] Error 2
can someone please either send me to the right list, or tell me what I
should do.

You are missing the CRT, see mingw-w64-crt.

my configure options are as follows:

libtool --finish /tools/libexec/gcc/x86_64-w64-mingw32/x.x.x/
AR=x86_64-w64-mingw32-ar RANLIB=x86_64-w64-mingw32-ranlib \
../gcc-4.5.1/configure --prefix=/tools \
--with-local-prefix=/tools --enable-clocale=gnu \
--enable-shared --enable-threads=posix \
--enable-__cxa_atexit --enable-languages=c,c++ \
--disable-libstdcxx-pch --disable-multilib \
--disable-bootstrap --disable-libgomp \
--without-ppl --without-cloog --build=x86_64-suse-linux-gnu
--host=x86_64-suse-linux-gnu --target=x86_64-w64-mingw32

You'd run into problems setting AR and RANLIB like that, let autotools
do its job.

As I said, I'm just following directions from LSF (Linux From Scratch)
http://archive.linuxfromscratch.org/lfs-museum/6.6/LFS-BOOK-6.6-HTML/chapter05/gcc-pass2.html

Everything I've done is based on this and another reference. Combined with
some of my own figuring out how to make it work.

Posix thread isn't for the faint hearted, you need to bootstrap
winpthread dll with libgcc, but DLLs can't be built without libgcc. I
suggest you remove --enable-threads=posix unless you have some special
needs, let gcc use the more tested win32 threads.

I recently found a reference that shows some threads being win32 rather then
pthreads --with-libgc-threads=w32 is another option I've seen recently,
and I was wondering if there is also --with-msvc-threads I can't seem to
find that exactly though. No there is no need for pthreads accept for just
figuring out the right options right now.

You are also missing essential options like
--enable-fully-dynamic-strings and --enable-sjlj-exceptions, you are
likely to break ABI from the auto builds. Finally, remove
--enable-__cxa_atexit, it will only work for glibc based hosts as far as
I know.

I'll try the flags you are suggesting, would you suggest I do anything
different for Pass 1 of building binutils, and gcc?
I skipped the Linux Headers, and glibc, and just use mingw-64 headers, and
msvc headers.
Also I had to do that before I made gcc pass 1. rather then after. otherwise
gcc doesn't build right without the mingw headers.

Please refer to the LFS book for more reference to what I'm talking about.
If you want I can send you the entire history of commands I have done (in
the order I did them), I write them all down so I can reproduce it if I have
to.
This also includes where I get my sources from.

Thank you for the input and help thus far.

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security
threats, fraudulent activity, and more. Splunk takes this data and makes
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] building gcc

2011-07-03 Thread Ruben Van Boxem

2011/7/3 Bj Raz whitequill...@gmail.com:
On Sun, Jul 3, 2011 at 6:06 AM, JonY jo...@users.sourceforge.net wrote:

See mingw-w64-docs for help on building. A lot of LFS doesn't apply to
mingw-w64.

You are missing the CRT, see mingw-w64-crt.

my configure options are as follows:

You'd run into problems setting AR and RANLIB like that, let autotools
do its job.

As I said, I'm just following directions from LSF (Linux From Scratch)
http://archive.linuxfromscratch.org/lfs-museum/6.6/LFS-BOOK-6.6-HTML/chapter05/gcc-pass2.html
Everything I've done is based on this and another reference. Combined with
some of my own figuring out how to make it work.

It would probably be easier for you to use the options that work: you
can look at my scripts (if you can read basic Bash) here:
https://github.com/rubenvb/MinGW-w64-build-scripts/tree/master/toolchain

If you select a versioned tag, like 4.6.1-3, it will be guaranteed to
work (if you have the source directories set up correctly), especially
if you download a source package, which includes everything you'll
need:
https://github.com/rubenvb/MinGW-w64-build-scripts/tree/master/toolchain

Modify the host and target and build values in the build*.sh scripts,
and run them: the buildcross*.sh build a cross-compiler, the
buildmingw*.sh build a native compiler. If you're on MSYS, you won't
need the cross compiler step.

The options used to build every bit are in the scripts directory,
mostly in the scripts named after the package, otherwise in the
common.sh script. Be sure to use the latest tag, because the master
branch is quite a mess (cough: read work in progress :) ).

Ruben

Thank you for the input and help thus far.

Re: [Mingw-w64-public] building gcc

2011-07-03 Thread Bj Raz

On Sun, Jul 3, 2011 at 4:22 PM, Ruben Van Boxem vanboxem.ru...@gmail.comwrote:

2011/7/3 Bj Raz whitequill...@gmail.com:
On Sun, Jul 3, 2011 at 6:06 AM, JonY jo...@users.sourceforge.net
wrote:

On 7/3/2011 12:10, Bj Raz wrote:
I've been working on cross compiler for building w64 binaries. I just
wanted to see if I could do it :P
I'm following the directions from Linux From Scratch (modifying them
as
needed).
So I've built gcc with c++ support and I have the errors:

See mingw-w64-docs for help on building. A lot of LFS doesn't apply to
mingw-w64.

You are missing the CRT, see mingw-w64-crt.

my configure options are as follows:

You'd run into problems setting AR and RANLIB like that, let autotools
do its job.

As I said, I'm just following directions from LSF (Linux From Scratch)

http://archive.linuxfromscratch.org/lfs-museum/6.6/LFS-BOOK-6.6-HTML/chapter05/gcc-pass2.html
Everything I've done is based on this and another reference. Combined
with
some of my own figuring out how to make it work.

I recently found a reference that shows some threads being win32 rather
then
pthreads --with-libgc-threads=w32 is another option I've seen recently,
and I was wondering if there is also --with-msvc-threads I can't seem
to
find that exactly though. No there is no need for pthreads accept for
just
figuring out the right options right now.

I'll try the flags you are suggesting, would you suggest I do anything
different for Pass 1 of building binutils, and gcc?
I skipped the Linux Headers, and glibc, and just use mingw-64 headers,
and
msvc headers.
Also I had to do that before I made gcc pass 1. rather then after.
otherwise
gcc doesn't build right without the mingw headers.

Please refer to the LFS book for more reference to what I'm talking
about.
If you want I can send you the entire history of commands I have done (in
the order I did them), I write them all down so I can reproduce it if I
have
to.
This also includes where I get my sources from.

No. My host is x86_64-suse-linux-gnu. Cause msys/mingw doesn't have enough
in it to build its self very well.

Ruben

I've included everything I've done up to this point.

Thank you for the input and help thus far.

--
All of the data generated in your IT

Re: [Mingw-w64-public] building gcc

2011-07-03 Thread Bj Raz

On Sun, Jul 3, 2011 at 5:45 PM, Ruben Van Boxem vanboxem.ru...@gmail.comwrote:

2011/7/3 Bj Raz whitequill...@gmail.com:

On Sun, Jul 3, 2011 at 4:22 PM, Ruben Van Boxem
vanboxem.ru...@gmail.com
wrote:

2011/7/3 Bj Raz whitequill...@gmail.com:
On Sun, Jul 3, 2011 at 6:06 AM, JonY jo...@users.sourceforge.net
wrote:

On 7/3/2011 12:10, Bj Raz wrote:
I've been working on cross compiler for building w64 binaries. I
just
wanted to see if I could do it :P
I'm following the directions from Linux From Scratch (modifying
them
as
needed).
So I've built gcc with c++ support and I have the errors:

See mingw-w64-docs for help on building. A lot of LFS doesn't apply
to
mingw-w64.

/tools/x86_64-w64-mingw32/bin/ld cannot find dllcrt2.o: No such
file
or directory
/tools/x86_64-w64-mingw32/bin/ld cannot find crtbegin.o: No such
file
or directory
/tools/x86_64-w64-mingw32/bin/ld cannot find crtend.o: No such file
or
directory
collect2: ld returned 1 exit status
make[2]: *** [libgcc_s.dll] Error 1
make[1]: *** [all-target-libgcc] Error 2
make: *** [all] Error 2
can someone please either send me to the right list, or tell me
what
I
should do.

You are missing the CRT, see mingw-w64-crt.

my configure options are as follows:

You'd run into problems setting AR and RANLIB like that, let
autotools
do its job.

As I said, I'm just following directions from LSF (Linux From Scratch)

Posix thread isn't for the faint hearted, you need to bootstrap
winpthread dll with libgcc, but DLLs can't be built without libgcc. I
suggest you remove --enable-threads=posix unless you have some
special
needs, let gcc use the more tested win32 threads.

I recently found a reference that shows some threads being win32
rather
then
pthreads --with-libgc-threads=w32 is another option I've seen
recently,
and I was wondering if there is also --with-msvc-threads I can't
seem
to
find that exactly though. No there is no need for pthreads accept for
just
figuring out the right options right now.

I'll try the flags you are suggesting, would you suggest I do anything
different for Pass 1 of building binutils, and gcc?
I skipped the Linux Headers, and glibc, and just use mingw-64 headers,
and
msvc headers.
Also I had to do that before I made gcc pass 1. rather then after.
otherwise
gcc doesn't build right without the mingw headers.

Please refer to the LFS book for more reference to what I'm talking
about.
If you want I can send you the entire history of commands I have done
(in
the order I did them), I write them all down so I can reproduce it if
I
have
to.
This also includes where I get my sources from.

It would probably be easier for you to use the options that work: you
can look at my scripts (if you can read basic Bash) here:

https://github.com/rubenvb/MinGW-w64-build-scripts/tree/master/toolchain

No. My host is x86_64-suse-linux-gnu. Cause msys/mingw doesn't have
enough
in it to build its self very well.

OK, change the buildcross*.sh scripts to this:
HOST=x86_64-suse-linux-gnu
TARGET=*-w64-mingw32
BUILD=x86_64-suse-linux-gnu

where * is either x86_64 or i686. The buildmingw*.sh scripts need:
HOST=*-w64-mingw32

Re: [Mingw-w64-public] building gcc

2011-07-03 Thread Bj Raz

On Sun, Jul 3, 2011 at 6:06 AM, JonY jo...@users.sourceforge.net wrote:

 On 7/3/2011 12:10, Bj Raz wrote:
  I've been working on cross compiler for building w64 binaries. I just
  wanted to see if I could do it :P
  I'm following the directions from Linux From Scratch (modifying them as
 needed).
  So I've built gcc with c++ support and I have the errors:
 

 See mingw-w64-docs for help on building. A lot of LFS doesn't apply to
 mingw-w64.

  /tools/x86_64-w64-mingw32/bin/ld cannot find dllcrt2.o: No such file
  or directory
  /tools/x86_64-w64-mingw32/bin/ld cannot find crtbegin.o: No such file
  or directory
  /tools/x86_64-w64-mingw32/bin/ld cannot find crtend.o: No such file or
 directory
  collect2: ld returned 1 exit status
  make[2]: *** [libgcc_s.dll] Error 1
  make[1]: *** [all-target-libgcc] Error 2
  make: *** [all] Error 2
  can someone please either send me to the right list, or tell me what I
  should do.
 

 You are missing the CRT, see mingw-w64-crt.

and yes, I didn't have the crt for mingw, I looked all over for it, and that
was the only one I could find. :-/


  my configure options are as follows:
 
  libtool --finish /tools/libexec/gcc/x86_64-w64-mingw32/x.x.x/
  AR=x86_64-w64-mingw32-ar RANLIB=x86_64-w64-mingw32-ranlib \
  ../gcc-4.5.1/configure --prefix=/tools \
  --with-local-prefix=/tools --enable-clocale=gnu \
  --enable-shared --enable-threads=posix \
  --enable-__cxa_atexit --enable-languages=c,c++ \
  --disable-libstdcxx-pch --disable-multilib \
  --disable-bootstrap --disable-libgomp \
  --without-ppl --without-cloog --build=x86_64-suse-linux-gnu
  --host=x86_64-suse-linux-gnu --target=x86_64-w64-mingw32
 

 You'd run into problems setting AR and RANLIB like that, let autotools
 do its job.

If you don't I'm pretty sure it will set the host RANLIB, and AR, bye
default which I don't want.
I want it to use the ones I just built in phase 1.


 Posix thread isn't for the faint hearted, you need to bootstrap
 winpthread dll with libgcc, but DLLs can't be built without libgcc. I
 suggest you remove --enable-threads=posix unless you have some special
 needs, let gcc use the more tested win32 threads.

 You are also missing essential options like
 --enable-fully-dynamic-strings and --enable-sjlj-exceptions, you are

what does --enable-fully dynamic-strings do, as well as
--enable-sjij=exceptions?

 likely to break ABI from the auto builds. Finally, remove
 --enable-__cxa_atexit, it will only work for glibc based hosts as far as
 I know.



 --
 All of the data generated in your IT infrastructure is seriously valuable.
 Why? It contains a definitive record of application performance, security
 threats, fraudulent activity, and more. Splunk takes this data and makes
 sense of it. IT sense. And common sense.
 http://p.sf.net/sfu/splunk-d2d-c2
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] building gcc

2011-07-03 Thread JonY

On 7/4/2011 08:49, Bj Raz wrote:

 /tools/x86_64-w64-mingw32/bin/ld cannot find dllcrt2.o: No such file
 or directory
 /tools/x86_64-w64-mingw32/bin/ld cannot find crtbegin.o: No such file
 or directory
 /tools/x86_64-w64-mingw32/bin/ld cannot find crtend.o: No such file or
 directory
 collect2: ld returned 1 exit status
 make[2]: *** [libgcc_s.dll] Error 1
 make[1]: *** [all-target-libgcc] Error 2
 make: *** [all] Error 2
 can someone please either send me to the right list, or tell me what I
 should do.


 You are missing the CRT, see mingw-w64-crt.

 and yes, I didn't have the crt for mingw, I looked all over for it, and that
 was the only one I could find. :-/
 

See the svn repo. You need stage 1 gcc to build it, aka after make
install-gcc.


 my configure options are as follows:

 libtool --finish /tools/libexec/gcc/x86_64-w64-mingw32/x.x.x/
 AR=x86_64-w64-mingw32-ar RANLIB=x86_64-w64-mingw32-ranlib \
 ../gcc-4.5.1/configure --prefix=/tools \
 --with-local-prefix=/tools --enable-clocale=gnu \
 --enable-shared --enable-threads=posix \
 --enable-__cxa_atexit --enable-languages=c,c++ \
 --disable-libstdcxx-pch --disable-multilib \
 --disable-bootstrap --disable-libgomp \
 --without-ppl --without-cloog --build=x86_64-suse-linux-gnu
 --host=x86_64-suse-linux-gnu --target=x86_64-w64-mingw32


 You'd run into problems setting AR and RANLIB like that, let autotools
 do its job.

 If you don't I'm pretty sure it will set the host RANLIB, and AR, bye
 default which I don't want.
 I want it to use the ones I just built in phase 1.
 

No, using host tools is correct, you aren't building a win64 hosted gcc
on Linux. Why do you want to use mingw target binutils when building for
Linux??


 Posix thread isn't for the faint hearted, you need to bootstrap
 winpthread dll with libgcc, but DLLs can't be built without libgcc. I
 suggest you remove --enable-threads=posix unless you have some special
 needs, let gcc use the more tested win32 threads.

 You are also missing essential options like
 --enable-fully-dynamic-strings and --enable-sjlj-exceptions, you are

 what does --enable-fully dynamic-strings do, as well as
 --enable-sjij=exceptions?

This disables lazy string init, this is required for libstdc++ DLL to
work properly, but it changes ABI. The latter uses SJLJ exception
handler, as the other type, dw2, doesn't work on win64.



0xED74C077.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] building gcc

2011-07-02 Thread Bj Raz

I've been working on cross compiler for building w64 binaries. I just
wanted to see if I could do it :P
I'm following the directions from Linux From Scratch (modifying them as needed).
So I've built gcc with c++ support and I have the errors:

/tools/x86_64-w64-mingw32/bin/ld cannot find dllcrt2.o: No such file
or directory
/tools/x86_64-w64-mingw32/bin/ld cannot find crtbegin.o: No such file
or directory
/tools/x86_64-w64-mingw32/bin/ld cannot find crtend.o: No such file or directory
collect2: ld returned 1 exit status
make[2]: *** [libgcc_s.dll] Error 1
make[1]: *** [all-target-libgcc] Error 2
make: *** [all] Error 2
can someone please either send me to the right list, or tell me what I
should do.

my configure options are as follows:

libtool --finish /tools/libexec/gcc/x86_64-w64-mingw32/x.x.x/
AR=x86_64-w64-mingw32-ar RANLIB=x86_64-w64-mingw32-ranlib \
../gcc-4.5.1/configure --prefix=/tools \
--with-local-prefix=/tools --enable-clocale=gnu \
--enable-shared --enable-threads=posix \
--enable-__cxa_atexit --enable-languages=c,c++ \
--disable-libstdcxx-pch --disable-multilib \
--disable-bootstrap --disable-libgomp \
--without-ppl --without-cloog --build=x86_64-suse-linux-gnu
--host=x86_64-suse-linux-gnu --target=x86_64-w64-mingw32

make 2 gcc2-error.log

just making sure I'm not missing something critical.

--
All of the data generated in your IT infrastructure is seriously valuable.
Why? It contains a definitive record of application performance, security 
threats, fraudulent activity, and more. Splunk takes this data and makes 
sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-d2d-c2
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] building GCC myself from MSYS

2010-09-15 Thread Ruben Van Boxem

I am now trying to rebuild the same GCC version (4.6-20100904) with my fresh
compiler, but getting stuck at either the stage2-stage3 comparison or if I
don't bootstrap, this:

xgcc.exe: error: C:UsersRubenAppDataLocalTempcccemHMa.lto.o: No such file or
 directory


Some MSYS path problem: same happens if you use backslashes '\' instead of
forward ones in pathnames... What made this happen?

Thanks!

Ruben
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] building GCC myself from MSYS

2010-09-14 Thread Ruben Van Boxem

2010/9/14 John E. / TDM tdra...@tdragon.net


 This is correct. TDM64 GCC 4.5.1 is patched to remove a leading underscore
 from the names of the _alloca and __chkstk symbols, in order for them to be
 exported from both the 64-bit and 32-bit versions of libgcc with the same
 export rule (there is another patch in TDM-GCC that requires this export).


I noticed last night and completed my first GCC build with an automated
build from mingw-w64. It didn't have any lto support, so I'll now be
recompiling to see if it can be enabled for GCC.

I'm not sure what the correct solution to this problem is, actually. I do
 know you can avoid it by performing a non-bootstrap build of GCC first and
 then using that build to do the bootstrap -- but ideally you wouldn't need
 to do that.


Well, doesn't it seem kind of wrong if mpfr has undefined symbols then? I
don't know anything about this, but why remove the underscores in the first
place? Perhaps it is better to have both versions (at least for x64)?

Ruben
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] building GCC myself from MSYS

2010-09-13 Thread John E. / TDM


 On 9/13/2010 11:34 AM, Ruben Van Boxem wrote:


M:/Development/msys/gcc-libs/lib/libmpfr.a(div.o):div.c:(.text+0xe75):
more undefined references to `__chkstk' follow
collect2: ld returned 1 exit status



How do i fix this? I'm doing a make profiledbootstrap in gcc, it has 
used mpfr before (in stage1) and didn't complain. Now in stage 
profile, I get these stupid errors... I fear it's some underscoring issue.


This is correct. TDM64 GCC 4.5.1 is patched to remove a leading 
underscore from the names of the _alloca and __chkstk symbols, in order 
for them to be exported from both the 64-bit and 32-bit versions of 
libgcc with the same export rule (there is another patch in TDM-GCC that 
requires this export).


I'm not sure what the correct solution to this problem is, actually. I 
do know you can avoid it by performing a non-bootstrap build of GCC 
first and then using that build to do the bootstrap -- but ideally you 
wouldn't need to do that.


-John E. / TDM
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing.
http://p.sf.net/sfu/novell-sfdev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] building GCC myself from MSYS

2010-09-12 Thread Ruben Van Boxem


 2010/9/11 John E. / TDM tdra...@tdragon.net

On 9/11/2010 12:19 PM, Kai Tietz wrote:

  , but nevertheless libelf (which
  isn't an elf OS specific library btw) is required so that LTO works as
  it should.

  Trust me, it isn't! I have never installed libelf on my build machine,
 but LTO is enabled and I see dramatic improvements when I use it.


 --
 Start uncovering the many advantages of virtual appliances
 and start using them to simplify application deployment and
 accelerate your shift to cloud computing
 http://p.sf.net/sfu/novell-sfdev2dev
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


I don't think the absence of libelf is the problem here. There are no
missing include files, and no ld error messages about undefined references
or missing libs. It's the lto-wrapper that has some odd buffer reading
problem (lto1 tries to read 0 bytes beyond end of buffer nothing wrong
with that?) when compiling libgcc_s with an intermediate compiler called
xgcc.
Just for the record, this is what I'm using:
gmp 5.0.1
mpfr 3.0.0
mpc 0.8.2
libiconv 1.13.1
binutils 2.20.51
gcc 4.6-20100904
mingw-w64 20100909
(libelf 0.8.9)
 ...

Now I've gotten further by removing my CFLAGS=-flto and LFLAGS=-flto
(I'll have to find out how to get them working for the final compile; is
there something like STAGE3_CFLAGS and
--enable-stage2-languages=c,c++,lto?).

I had to copy TDM64's pthread library and header to the sysroot directory,
and libgomp built fine (still stage1 I think).

Now I get an error in libcpp:

../../../src/gcc/libcpp/files.c: In function 'read_file_guts':

../../../src/gcc/libcpp/files.c:609:7: error: comparison is always false due
 to limited range of data type [-Werror=type-limits]For now I have
 reconfigured with --disable-werror to work around this.


A new question has also popped into my mind: for x86_64, is something like
-march=k8 automatically enabled for? Because it should be, as -march=k8 is
equivalent to the x86_64 instruction set, if I read the docs correctly.

Thanks,

Ruben
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] building GCC myself from MSYS

2010-09-11 Thread Ruben Van Boxem

Hi,

Recently I started messing around with GCC and attempted to build it many
times. I first had lots of trouble with the 4.5 snapshots, but have now
moved to 4.6 and all seems well. I put all the instructions in a single file
(not quite a script, but almost, if you're willing to call a file with
commands a script).

The goal is to build an optimized GCC for myself and perhaps later (when I'm
confident about the quality of it) I can upload it to Sourceforge.

The commands are loosely based on makebuildroot.sh from mingw-w64 svn. For
now no multilib, but I have enabled lto and whole-program optimization,
along with -mtune=core2 for all parts of the process.

I do have some specific questions though:
1. Is there still an installation and/or other issue with multilib and GCC
4.6 or is that all fixed now?
2. Would -fomit-frame-pointer help optimization?
3. Is it smart to enable 4.5's lto to a 4.6 source, or should I first get a
4.6 GCC built without it?

Thanks!

Ruben
#
#Required tools:#
#
# - GCC/mingw-w64 for host platform (lto requires 4.5.1+)
# - flex
# - bison
# - makeinfo

##
#Sources:#
##
#libiconv
#Binutils
#libelf
#gmp
#mpfr
#mpc
#GCC
#mingw-w64

###
#Directory layout:#
###
#root
#root/mingw64-old -- binary toolchain used for compilation
#root/src
#root/src/libiconv
#root/src/binutils
#root/src/libelf
#root/src/gmp
#root/src/mpfr
#root/src/mpc
#root/src/gcc
#root/src/mingw-w64
#root/build
#root/build/binutils
#root/build/libelf
#root/build/gmp
#root/build/mpfr
#root/build/mpc
#root/build/gcc
#root/build/mingw-w64-crt
#root/build/mingw64 -- this is where everything will be installed
#root/build/mingw64/bin -- location of new compiler

##
#Build steps from root:#
##
#prepare
# allow eg iconv-0.dll to be found
export PATH=/mingw/x86_64-w64-mingw32/bin:$PATH
# allow new tools to be found
export PATH=/home/ruben/mingw64/build/mingw64/bin:$PATH

cd build

#libiconv
cd libiconv
../../src/libiconv/configure --prefix=/mingw/x86_64-w64-mingw32 
--host=x86_64-w64-mingw32 CFLAGS=-mtune=core2 -flto LFLAGS=-flto -fwhopr=3
make
make install
cd ..
# binutils
cd binutils
../../src/binutils/configure --prefix=/home/ruben/mingw64/build/mingw64 
--with-sysroot=/home/ruben/mingw64/build/mingw64 --target=x86_64-w64-mingw32 
--host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --enable-lib64 
--disable-lib32 CFLAGS=-mtune=core2 -flto LFLAGS=-flto -fwhopr=3
make
make install
cd ..
# libelf - no optimizations possible
cd libelf
../../src/libelf/configure --prefix==/mingw/x86_64-w64-mingw32 
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
make
make install
cd ..
# gmp
cd gmp
../../src/gmp/configure --prefix=/mingw/x86_64-w64-mingw32 
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 CFLAGS=-mtune=core2 
-flto LFLAGS=-flto -fwhopr=3
make
make install
cd ..
# mpfr
cd mpfr
../../src/mpfr/configure --prefix=/mingw/x86_64-w64-mingw32 
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 CFLAGS=-mtune=core2 
-flto LFLAGS=-flto -fwhopr=3
make
make install
cd ..
# mpc
cd mpc
../../src/mpc/configure --prefix=/mingw/x86_64-w64-mingw32 
--build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32 CFLAGS=-mtune=core2 
-flto LFLAGS=-flto -fwhopr=3
make
make install
cd ..
# mingw-w64
cd build/mingw-w64
../../src/mingw-w64/configure --prefix=/home/ruben/mingw64/build/mingw64 
--with-sysroot=/home/ruben/mingw64/build/mingw64 --target=x86_64-w64-mingw32 
--host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --disable-lib32 
--enable-lib64 CFLAGS=-mtune=core2 -flto LFLAGS=-flto -fwhopr=3
make
make install
cd ..
cp mingw64/x86_64-w64-mingw32/include mingw64/mingw/include
# gcc
cd gcc
../../src/gcc/configure --prefix=/home/ruben/mingw64/build/mingw64 
--with-sysroot=/home/ruben/mingw64/build/mingw64 --target=x86_64-w64-mingw32 
--host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 
--enable-languages=c,c++,lto --enable-stage1-languages=c,c++,lto 
--enable-fully-dynamic-string --disable-multilib  --enable-lib64 
--disable-lib32 --enable-lto --enable-libgomp CFLAGS=-mtune=core2 -flto 
LFLAGS=-flto -fwhopr=3 BOOT_CFLAGS=-mtune=core2 -flto BOOT_LFLAGS=-flto 
-fwhopr=3
make #profiledbootstrap
make install
cd ..
#set up path
export PATH=/home/ruben/mingw64/build/mingw64/bin:$PATH

# full gcc
cd gcc
make
make install
cd ..
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] building GCC myself from MSYS

2010-09-11 Thread Ruben Van Boxem

2010/9/11 Ruben Van Boxem vanboxem.ru...@gmail.com

 Hi,

 Recently I started messing around with GCC and attempted to build it many
 times. I first had lots of trouble with the 4.5 snapshots, but have now
 moved to 4.6 and all seems well. I put all the instructions in a single file
 (not quite a script, but almost, if you're willing to call a file with
 commands a script).

 The goal is to build an optimized GCC for myself and perhaps later (when
 I'm confident about the quality of it) I can upload it to Sourceforge.

 The commands are loosely based on makebuildroot.sh from mingw-w64 svn. For
 now no multilib, but I have enabled lto and whole-program optimization,
 along with -mtune=core2 for all parts of the process.

 I do have some specific questions though:
 1. Is there still an installation and/or other issue with multilib and GCC
 4.6 or is that all fixed now?
 2. Would -fomit-frame-pointer help optimization?
 3. Is it smart to enable 4.5's lto to a 4.6 source, or should I first get a
 4.6 GCC built without it?

 Thanks!

 Ruben


I've run into a rather crappy problem:

Creating library file: ./shlib/libgcc_s.a.tmp
 lto1.exe: internal compiler error: bytecode stream: trying to read 0 bytes
 after the end of the input buffer
 Please submit a full bug report,
 with preprocessed source if appropriate.
 See http://gcc.gnu.org/bugs.html for instructions.
 lto-wrapper: M:\Development\msys\home\Ruben\mingw64\build\gcc\gcc\xgcc.exe
 returned 1 exit status
 collect2: lto-wrapper returned 1 exit status
 make[3]: *** [libgcc_s.dll] Error 1


I think this is the bootstrapped compiler trying to compile libgcc with lto
failing (right?). I'll try disabling the lto in stage1 and see what that
gives.

Ruben
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] building GCC myself from MSYS

2010-09-11 Thread Kai Tietz

2010/9/11 Ruben Van Boxem vanboxem.ru...@gmail.com:
 2010/9/11 Ruben Van Boxem vanboxem.ru...@gmail.com

 Hi,

 Recently I started messing around with GCC and attempted to build it many
 times. I first had lots of trouble with the 4.5 snapshots, but have now
 moved to 4.6 and all seems well. I put all the instructions in a single file
 (not quite a script, but almost, if you're willing to call a file with
 commands a script).

 The goal is to build an optimized GCC for myself and perhaps later (when
 I'm confident about the quality of it) I can upload it to Sourceforge.

 The commands are loosely based on makebuildroot.sh from mingw-w64 svn. For
 now no multilib, but I have enabled lto and whole-program optimization,
 along with -mtune=core2 for all parts of the process.

 I do have some specific questions though:
 1. Is there still an installation and/or other issue with multilib and GCC
 4.6 or is that all fixed now?
 2. Would -fomit-frame-pointer help optimization?
 3. Is it smart to enable 4.5's lto to a 4.6 source, or should I first get
 a 4.6 GCC built without it?

 Thanks!

 Ruben

 I've run into a rather crappy problem:

 Creating library file: ./shlib/libgcc_s.a.tmp
 lto1.exe: internal compiler error: bytecode stream: trying to read 0 bytes
 after the end of the input buffer
 Please submit a full bug report,
 with preprocessed source if appropriate.
 See http://gcc.gnu.org/bugs.html for instructions.
 lto-wrapper: M:\Development\msys\home\Ruben\mingw64\build\gcc\gcc\xgcc.exe
 returned 1 exit status
 collect2: lto-wrapper returned 1 exit status
 make[3]: *** [libgcc_s.dll] Error 1

 I think this is the bootstrapped compiler trying to compile libgcc with lto
 failing (right?). I'll try disabling the lto in stage1 and see what that
 gives.

 Ruben


 --
 Start uncovering the many advantages of virtual appliances
 and start using them to simplify application deployment and
 accelerate your shift to cloud computing
 http://p.sf.net/sfu/novell-sfdev2dev

 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public



Hmm, I don't get this failure on cygwin as host. Have you installed
lto on msys for native compiler before proper?

Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] building GCC myself from MSYS

2010-09-11 Thread Ruben Van Boxem


 Hmm, I don't get this failure on cygwin as host. Have you installed

lto on msys for native compiler before proper?

 Kai


I'm using TDM64 GCC 4.5.1 with lto enabled, and it works for eg building Qt
without error. I have also built and installed libelf for TDM64 GCC (it's
installed in the MSYS /mingw/x86_64-w64-mingw32 directory, with /mingw a
symlink to the TDM64 root directory.

I am now trying with these options:

../../src/gcc/configure --prefix=/home/ruben/mingw64/build/mingw64
 --with-sysroot=/home/ruben/mingw64/build/mingw64 --target=x86_64-w64-mingw32
 --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32
 --enable-languages=c,c++,lto --enable-stage1-languages=c,c++,lto
 --enable-fully-dynamic-string --disable-multilib --enable-lib64
 --disable-lib32 --enable-lto --enable-libgomp CFLAGS=-mtune=core2 -flto
 LFLAGS=-flto -fwhopr=3 BOOT_CFLAGS=-mtune=core2 BOOT_LFLAGS=-whopr=3


In the hope that BOOT_LFLAGS will overwrite the regular LFLAGS for the
bootstrapping compiler.

Am I correct in thinking that configure options  make (make install)
is all I need?
Could I perhaos have a look at your build script/commands (if it's not just
the one from svn...).

Thanks

Ruben
--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] building GCC myself from MSYS

2010-09-11 Thread Kai Tietz

2010/9/11 Ruben Van Boxem vanboxem.ru...@gmail.com:
 Hmm, I don't get this failure on cygwin as host. Have you installed

 lto on msys for native compiler before proper?

 Kai

 I'm using TDM64 GCC 4.5.1 with lto enabled, and it works for eg building Qt
 without error. I have also built and installed libelf for TDM64 GCC (it's
 installed in the MSYS /mingw/x86_64-w64-mingw32 directory, with /mingw a
 symlink to the TDM64 root directory.

 I am now trying with these options:

 ../../src/gcc/configure --prefix=/home/ruben/mingw64/build/mingw64
 --with-sysroot=/home/ruben/mingw64/build/mingw64 --target=x86_64-w64-mingw32
 --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32
 --enable-languages=c,c++,lto --enable-stage1-languages=c,c++,lto
 --enable-fully-dynamic-string --disable-multilib --enable-lib64
 --disable-lib32 --enable-lto --enable-libgomp CFLAGS=-mtune=core2 -flto
 LFLAGS=-flto -fwhopr=3 BOOT_CFLAGS=-mtune=core2 BOOT_LFLAGS=-whopr=3

 In the hope that BOOT_LFLAGS will overwrite the regular LFLAGS for the
 bootstrapping compiler.

 Am I correct in thinking that configure options  make (make install)
 is all I need?
 Could I perhaos have a look at your build script/commands (if it's not just
 the one from svn...).

 Thanks

 Ruben



Well, lto normally needs not to be explicit enabled. You just need to
have the libelf library installed on you host environment. I assume
that this is the issue you are seeing here, that libelf isn't present.

Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] building GCC myself from MSYS

2010-09-11 Thread Kai Tietz

2010/9/11 John E. / TDM tdra...@tdragon.net:
  On 9/11/2010 11:50 AM, Kai Tietz wrote:
 Well, lto normally needs not to be explicit enabled. You just need to
 have the libelf library installed on you host environment.

 Actually, libelf is not required to enable LTO for PE-COFF targets (i.e.
 Windows), since PE-COFF and ELF are two different formats. Due to the
 excellent work of Dave Korn, GCC has a built-in LTO translator for
 PE-COFF, and all you need is --enable-lto at configure time (see
 http://gcc.gnu.org/ml/gcc-patches/2010-04/msg00612.html).

 -John E. / TDM

 --
 Start uncovering the many advantages of virtual appliances
 and start using them to simplify application deployment and
 accelerate your shift to cloud computing
 http://p.sf.net/sfu/novell-sfdev2dev
 ___
 Mingw-w64-public mailing list
 Mingw-w64-public@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


Well, AFAIK (and I use libelf on cygwin) it works nice with libelf.
The issue is that LTO internally stores information in elf (within PE
coff sections). So I doubt what you are telling me, as my expirence
here tells me something else. Dave Korn ported the LTO backend for
COFF to encapsulate ELF into sections, but nevertheless libelf (which
isn't an elf OS specific library btw) is required so that LTO works as
it should.

Regards,
Kai

-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| ()_() him gain world domination

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] building GCC myself from MSYS

2010-09-11 Thread John E. / TDM

  On 9/11/2010 12:19 PM, Kai Tietz wrote:
 , but nevertheless libelf (which
 isn't an elf OS specific library btw) is required so that LTO works as
 it should.

Trust me, it isn't! I have never installed libelf on my build machine, 
but LTO is enabled and I see dramatic improvements when I use it.

--
Start uncovering the many advantages of virtual appliances
and start using them to simplify application deployment and
accelerate your shift to cloud computing
http://p.sf.net/sfu/novell-sfdev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

46 matches

Mail list logo