On 7/2/2009 21:40, McWilliams, Steven wrote:
If I have the msys /etc/fstab setting /c/mingw_64 /mingw and I try to
compile a little hello-world type C program via gcc.exe hello.c I get the
error sh: gcc exe: command not found, which makes sense since
c:\mingw_64\bin does not have a gcc.exe
On 8/17/2009 16:30, Ozkan Sezer wrote:
On Mon, Aug 17, 2009 at 10:49 AM, JonY10wa...@gmail.com wrote:
Hi,
This patch will add warning flags.
There are currently 5 warning levels, which defaults to level 3. It gets
noisier for higher levels. Level 0 is equivalent to no additional flags. Use
On 8/17/2009 19:12, Erik Leunissen wrote:
After having experimented with gendef, I'd like to suggest a few changes
regarding the .def output:
The format of the generated .def file differs from the .def files around
the globe in two ways:
- it has a program info header
- it surrounds the
On 8/17/2009 22:37, NightStrike wrote:
1) Put the AC_MSG_CHECKING at the beginning, before you start the checking.
Ok, done.
2) Features like this should be an enable thing, not a with thing.
with things are more for external tools.
Ok, done. I was wondering about that...
3) Keep the
On 8/18/2009 00:28, JonY wrote:
On 8/17/2009 22:37, NightStrike wrote:
1) Put the AC_MSG_CHECKING at the beginning, before you start the
checking.
Ok, done.
2) Features like this should be an enable thing, not a with thing.
with things are more for external tools.
Ok, done. I
On 8/24/2009 20:15, Sisyphus wrote:
Hi,
I'm running Vista64, and I got my mingw-w64 compiler from the
mingw-w64-bin_i686-mingw_20090819.zip package.
I have the 64-bit builds of gmp and mpfr that come with
mingw-w64-bin-gmp-mpfr-20080604.tar.bz2 .
In the latter package, mpfr is still at
Starting New Thread
On 8/25/2009 07:53, Sisyphus wrote:
You can build 2.4.x it from source, grab it at http://www.mpfr.org/.
Yes, I already have the source. I guess I could use the provided gmp
binaries to build mpfr, but I would prefer to use a gmp I had built myself.
Also, building my
On 8/26/2009 21:19, sisyph...@optusnet.com.au wrote:
I hacked my way past this problem as follows:
In both src/set_x.c and src/set_x_x.c I changed:
#if HAVE_INTTYPES_H
to
#if 1
and I changed
#ifdef _MPC_H_HAVE_INTMAX_T
to
#if 1
Then ran 'make distclean' and started afresh. All was
On 8/27/2009 02:44, Sisyphus wrote:
Hi JonY,
config.log.gz is attached.
Hi,
strangely, at the end of the config.log, I find at the end of config.log:
#define HAVE_INTTYPES_H 1
Maybe some file wasn't including config.h right, or erroneously using
pthreads config.h
On 9/10/2009 04:18, Matthew Talbert wrote:
You aren't building with a separate prefix, so you are installing
right into your root. This can cause issues if you have conflicting
versions of things installed. You are best to install into some
prefix outside of your main tree until you get the
On 9/10/2009 09:59, Matthew Talbert wrote:
Use 'svn export include /mypath/x86_64-w64-mingw32/include'. It will
create the missing directory and copy the headers without the svn
metadata. The metadata is in a .svn subdirectory in each directory you
checkout via svn.
Perhaps I should have
On 9/10/2009 11:27, Matthew Talbert wrote:
Perhaps I should have mentioned earlier, I'm compiling from the 4.4.0
release, not from svn. Still, the directions are wrong, yes? (They
neglect the trailing include directory, so you would be copying the
contents of include to
On 9/10/2009 11:22, Matthew Talbert wrote:
/opt/w64/bin/x86_64-w64-mingw32-gcc -print-prog-name=as
as
According to your build script, you should have cross binutils already
installed, -print-prog-name=as is to make sure it is calling the correct
cross binutils. Do post the output, thanks.
On 9/10/2009 12:06, Matthew Talbert wrote:
On Wed, Sep 9, 2009 at 11:44 PM, JonY10wa...@gmail.com wrote:
On 9/10/2009 11:22, Matthew Talbert wrote:
/opt/w64/bin/x86_64-w64-mingw32-gcc -print-prog-name=as
as
According to your build script, you should have cross binutils already
On 9/14/2009 02:46, Wolfgang Glas wrote:
Hi all,
After getting our clazzes.org PPA
(https://www.launchpad.net/~clazzes.org/+archive/ppa) seeded with many
backported libraries, I was finally able to release a cross-compiled qt-4.5.2
version for win32 and win64.
There are a number of
On 9/14/2009 20:41, Wolfgang Glas wrote:
JonY schrieb:
On 9/14/2009 02:46, Wolfgang Glas wrote:
[snip]
The mileage up to know is quite mixed, Qt Designer is running well, othe
simple Qt examples are crashing by now.
For earlier posting I suppose, that these crashes might be caused
On 9/17/2009 08:52, Erik de Castro Lopo wrote:
Hi all,
I'm currently using :
mingw-w64-bin_i686-linux_20090202.tar.bz2
and ran into some troubles (%zd in printf format strings not
supported) and was going to grab a later version.
Unfortunately I can't seem to find one on the web
On 9/17/2009 10:43, Erik de Castro Lopo wrote:
JonY wrote:
the most recent build for 32bit linux is
mingw-w64-bin_i686-linux_20090612.tar.bz2, but its hidden by sourceforge.
Sourceforge is amazing efficient at hiding files :-).
I just tried the file :
mingw-w64_x86-64_linux32_4.4.0
On 9/21/2009 06:42, Erik de Castro Lopo wrote:
NightStrike wrote:
Add TARGET_ARCH=i686-w64-mingw32 to your make command line.
Shouldn't that be i686-w32-mingw32 or maybe even i686-pc-mingw32?
Erik
Hi,
w64 is already a vendor key recognized by gcc. It will add support for
mingw-w64
On 9/21/2009 09:48, Erik de Castro Lopo wrote:
JonY wrote:
On 9/21/2009 06:42, Erik de Castro Lopo wrote:
NightStrike wrote:
Add TARGET_ARCH=i686-w64-mingw32 to your make command line.
Shouldn't that be i686-w32-mingw32 or maybe even i686-pc-mingw32?
w64 is already a vendor key
On 10/10/2009 11:53, t66...@gmail.com wrote:
JonY wrote:
On 10/10/2009 09:45, t66...@gmail.com wrote:
t66...@gmail.com wrote:
JonY wrote:
On 10/10/2009 08:04, t66...@gmail.com wrote:
t66...@gmail.com wrote:
t66...@gmail.com wrote:
x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -m32 -pipe -std
On 10/10/2009 14:13, t66...@gmail.com wrote:
JonY wrote:
On 10/10/2009 11:53, t66...@gmail.com wrote:
JonY wrote:
On 10/10/2009 09:45, t66...@gmail.com wrote:
t66...@gmail.com wrote:
JonY wrote:
On 10/10/2009 08:04, t66...@gmail.com wrote:
t66...@gmail.com wrote:
t66...@gmail.com wrote
On 1/12/2010 05:41, Frank R. Brown wrote:
To All:
I do not see a version of make in my mingw-w64 installation. Am I overlooking
something, or is this to be expected? (I have looked for things like
make.exe,
mingw-make.exe, mingw32-make.exe, etc.)
I downloaded and unzipped
On 1/12/2010 18:55, Ozkan Sezer wrote:
There actually are make binaries posted under
External binary packages (Win64 hosted) - make
on the downloads page. You can try downloading
make_20091224a_bin.tar.gz for example and
using it.
I didn't know about that. win64 hosted make should work
On 1/19/2010 16:51, Ozkan Sezer wrote:
On Tue, Jan 19, 2010 at 7:42 AM, Zuxy Meng wrote:
Hi,
I wonder if the win32api headers from mingw32 can be used directly in
mingw64.
No, they cannot.
If I have already a working msys+mingw32 env installed, can I just
copy binutils, gcc and libraries
On 1/19/2010 20:03, Sisyphus wrote:
- Original Message -
From: Ozkan Sezerseze...@gmail.com
Firstly, the command I'm running to build and test gmp-5.0.0 is:
./configure --disable-shared --enable-static --host=none-none-none
CC=x86_64-w64-mingw32-gcc -std=gnu99
On 1/19/2010 21:55, Ozkan Sezer wrote:
On Tue, Jan 19, 2010 at 3:50 PM, JonYjo...@users.sourceforge.net wrote:
On 1/19/2010 20:03, Sisyphus wrote:
- Original Message -
From: Ozkan Sezerseze...@gmail.com
Firstly, the command I'm running to build and test gmp-5.0.0 is:
./configure
On 1/26/2010 21:50, Chris Spencer wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hi all,
I'm having a bit of a problem with my networking code. Specifically, the
linker can't find gai_strerror().
To provide a very simple test case:
#includews2tcpip.h
int main() {
On 1/30/2010 12:11, David Cleaver wrote:
Hello again,
I know it wasn't long ago that I was asking about using %llu in fscanf or
sscanf. However, I am wondering if anything has changed in this regard? Does
MingW64 support %llu in the scanf functions?
Also, in the future, is there an easy
On 2/21/2010 21:35, NightStrike wrote:
On Fri, Jan 15, 2010 at 8:32 AM, Chris Sutcliffeir0nh...@gmail.com wrote:
Hi All,
Is it possible for i686-w64-mingw and x86_64-w64-mingw32 to coexist in
the same directory? I realize the majority of the directory structure
is unique to the compiler,
On 2/22/2010 07:59, Jim Michaels wrote:
compiler-defined #defines so you can write cross-platform code better.
one source code, multiple targets (djgpp, 9x/me, nt-family, vista/7).
I have a web page with a g++ wrapper batch file that makes vista/7-compatible
code by adding a manifest XML
On 3/22/2010 07:24, Doug Semler wrote:
On Sun, 21 Mar 2010 18:37:12 NightStrike wrote:
On Sun, Mar 21, 2010 at 2:10 PM, Doug Semlerdougsem...@gmail.com wrote:
Yeah, I kinda decided to give up on multilib with gcc 4.5 right now. The
target DLLs for things like libstdc++, etc are installed
On 3/24/2010 20:15, Sisyphus wrote:
Hi,
I've posted to gsl-bugs about this ... without success. I'm not even sure
that it's a gsl bug - there's a thread at
http://www.mail-archive.com/bug-libt...@gnu.org/msg00374.html where the
error is of a very similar type. In that particular instance it
On 4/16/2010 15:06, LunarShaddow wrote:
Thx for the help of NightStriker. Now i replaced the boehm-gc dir of the gcc
tree with the newer test edition
(I noted that the problem troubling me seemed to have been resolved in 2007
but not been imported to gcc...)
I compiled boehm-gc seperatedly
On 4/16/2010 15:06, LunarShaddow wrote:
Thx for the help of NightStriker. Now i replaced the boehm-gc dir of the gcc
tree with the newer test edition
(I noted that the problem troubling me seemed to have been resolved in 2007
but not been imported to gcc...)
I compiled boehm-gc seperatedly
On 5/4/2010 17:08, Dmitrijs Ledkovs wrote:
On 4 May 2010 10:03, Ozkan Sezerseze...@gmail.com wrote:
On Tue, May 4, 2010 at 10:53 AM, Dmitrijs Ledkovs
dmitrij.led...@ubuntu.com wrote:
On 4 May 2010 07:51, Ozkan Sezerseze...@gmail.com wrote:
On Tue, May 4, 2010 at 9:44 AM, Dmitrijs Ledkovs
On 5/4/2010 19:01, Dmitrijs Ledkovs wrote:
2010/5/4 kmxk...@volny.cz:
Hi,
could you please add the following 2 items to the list of Projects
successfully using MinGW-w64
1/ perl (5.12.0 and later) with link to http://www.perl.org/
2/ strawberry perl (contains bundled mingw-w64 gcc
On 5/4/2010 21:24, Dmitrijs Ledkovs wrote:
On 4 May 2010 12:57, JonYjo...@users.sourceforge.net wrote:
On 5/4/2010 18:58, Dmitrijs Ledkovs wrote:
On 4 May 2010 10:40, JonYjo...@users.sourceforge.netwrote:
On 5/4/2010 17:08, Dmitrijs Ledkovs wrote:
On 4 May 2010 10:03, Ozkan
On 5/6/2010 08:12, Jarrod Chesney wrote:
pavel wrote:
On Tue, 2010-05-04 at 13:26 +0200, pavel wrote:
why the latest release links the programs with the
libgcc_s_sjsj-1.dll? Is it possible to avoid that?
I have figured this out already.
Just for the record, how do you avoid this?
You
On 5/15/2010 11:34, Jim Michaels wrote:
one easy thing you could include with the compiler is a batch file which sets
the environment variables for the compiler. put it in the bin directory for
consistency.
the variables that need to be set (I think) at least, are
OBJC_INCLUDE_PATH
On 5/15/2010 12:12, Jim Michaels wrote:
1.
I have noticed that for sezero and auto compilers, there averages
7-8 LONG directories for lib path totalling 284-328 characters
5 LONG directories for include path totalling 274-310 characters
1-2
directories for bin path.
I suggest at least a
On 5/17/2010 18:23, t66...@gmail.com wrote:
Hello,
I'm using gcc-4.5 branch multi-lib cross compiler
And today I tries to compile GDB 7.1
gdb x86_64-w64 target build successfully
Trying to build mpfr host = i686-w64 or i686-pc
checking for __gmpz_init in -lgmp... no
configure: error:
On 5/31/2010 03:42, Hradec wrote:
Hi there...
before anything I would like to thank you all by the amazing mingw64... In
my opnion, the best mingw ever... really neat, simple and clean... well
done!!
I'm working on cross-compile openexr and ilmbase on a mac. I got the latest
darwin binary
On 5/31/2010 16:11, Hradec wrote:
thanks for the idea... just tried and now I got multiple definitions:
i686-w64-mingw32-g++
-I/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/pthreads/build/GC_x86_4.6.0_20100528/include/
On 6/1/2010 09:57, Hradec wrote:
cool... I'll try that!
a question... the ilmbase configure script if figuring all that out by
itself... I'm wondering if there's a default mechanism that a configure
script can use to query gcc in order to obtain those options... if so, is
there a way to
On 6/1/2010 10:30, Hradec wrote:
yeah... I already find it... the problem is that libtool is being generated
after the configure script, and my automatic build system runs before
configure, so I would have to patch configure in order to get it to output
libtool already patched... (kinda
On 6/2/2010 06:28, Hradec wrote:
Works!! I got it linking correctly... I actually found the libtool template
code inside configure, so it was pretty simple to delete it from there and
now I got a proper configure patch which generates a patched libtool.
Although it links correctly now, I'm
On 6/2/2010 10:08, Hradec wrote:
i686-w64-mingw32-g++
-I/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/pthreads/build/GC_x86_4.6.0_20100528/include/
-L/Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/pthreads/build/GC_x86_4.6.0_20100528/lib/
On 6/10/2010 01:41, Chris Saunders wrote:
I think that I installed MSYS correctly for my Windows 7 64-bit system. I
downloaded and attempted to run configure on GMP-5.0.1 and got some output
that made me think I have a problem:
$ ./configure --disable-shared --enable-alloca=no
checking
On 6/12/2010 14:19, Michael Adams wrote:
I heartily thank the developers for putting together this project: it
allowed me to port several pieces of software to 64-bit that I regularly
use.
http://unquietwiki.blogspot.com/2010/06/evening-spent-cranking-out-windows-x64.html
Hi,
To clear up
On 6/15/2010 20:30, Ruben Van Boxem wrote:
2010/6/15 JonYjo...@users.sourceforge.net
On 6/15/2010 19:31, Ruben Van Boxem wrote:
I didn't have such issues cross compiling GMP in Cygwin or Linux.
Well, MSYS is special :s (see other thread on my link.exe removal).
MSYS is not special at
On 6/15/2010 21:49, Ruben Van Boxem wrote:
Hmm, I think /mingw/bin or where your mingw-w64 toolchain bindir is should
always be before MSYS's bindir, and that . will certainly cause trouble
with GCC's build system.
That's exactly why I said MSYS is special... and I don't know what will
On 6/16/2010 01:37, Ruben Van Boxem wrote:
2010/6/15 JonYjo...@users.sourceforge.net
On 6/15/2010 21:49, Ruben Van Boxem wrote:
Hmm, I think /mingw/bin or where your mingw-w64 toolchain bindir is should
always be before MSYS's bindir, and that . will certainly cause trouble
with GCC's build
On 6/16/2010 18:51, Ruben Van Boxem wrote:
Either way, without more of the config log it's difficult to tell why
it's trying to use a half-msvc toolchain.
I have attached stderr and stdout logs for
configure --host=x86_64-w64-mingw32 --disable-shared --enable-alloca=no
the config.log file
On 7/1/2010 10:21, Paarvai Naai wrote:
As I have mentioned in some recent emails, I am building my mingw-w64
toolchain using upstream binutils-2.20.1, gcc 4.5.0, and
mingw-w64-v1.0-20100604 snapshot. The host is i386-linux and the
target is x86_64-w64-mingw32 with multilib support.
I am
On 7/1/2010 11:36, Paarvai Naai wrote:
Hi Jon,
Ah, it looks like a name mangling problem.
/usr/local/gcc/x86_64-windows-gcc/bin/x86_64-windows-nm hello.gcc.o
b .bss
d .data
r .rdata
t .text
T _wmain
On 7/27/2010 15:20, Dongsheng Song wrote:
Hi Jonathan,
Here is the patch:
Index: Makefile.in
===
--- Makefile.in(revision 2968)
+++ Makefile.in(working copy)
@@ -3697,7 +3697,7 @@
@LIB64_TRUE@ lib64/libks.a
On 7/28/2010 20:32, Dongsheng Song wrote:
于 2010-7-28 16:02, Kai Tietz 写道:
2010/7/28 Dongsheng Songdongsheng.s...@gmail.com:
于 2010-7-28 15:43, Kai Tietz 写道:
2010/7/28 Dongsheng Songdongsheng.s...@gmail.com:
Hi Kai,
When we cross build gcc 4.5 for windows, I found we can build windows gcc
On 7/29/2010 23:39, NightStrike wrote:
On Tue, Jul 27, 2010 at 5:01 AM, JonYjo...@users.sourceforge.net wrote:
On 7/27/2010 15:20, Dongsheng Song wrote:
Hi Jonathan,
Here is the patch:
Index: Makefile.in
===
--- Makefile.in
On 7/30/2010 09:50, Dongsheng Song wrote:
On Wed, Jul 28, 2010 at 21:42, JonYjo...@users.sourceforge.net wrote:
On 7/28/2010 20:32, Dongsheng Song wrote:
于 2010-7-28 16:02, Kai Tietz 写道:
2010/7/28 Dongsheng Songdongsheng.s...@gmail.com:
于 2010-7-28 15:43, Kai Tietz 写道:
2010/7/28
On 8/9/2010 09:01, Sisyphus wrote:
- Original Message -
From: Chris Saunderse...@mountaincable.net
To: MinGW 64-bitmingw-w64-public@lists.sourceforge.net
Sent: Monday, August 09, 2010 9:30 AM
Subject: [Mingw-w64-public] Installing MinGW 64-bit and MSYS
I had the 64-bit version
On 8/20/2010 21:25, Ozkan Sezer wrote:
I've been forgetting this for quite some time:
http://quakespasm.sourceforge.net/
We've been compiling for w64 using mingw-w64 for some time.
The project uses SDL, so we are including x64 builds of SDL
also prepared using mingw-w64. It has been
On 8/23/2010 06:27, Chris Saunders wrote:
If I run configure for GMP, MPFR, MPC and MPFI I get this warning from
configure:
configure: WARNING: If you wanted to set the --build type, don't use --host.
If a cross compiler is detected then cross compile mode will be used.
Now, all of
On 8/27/2010 09:37, mescali...@gmail.com wrote:
hi,
I just installed a mingw-w64 toolcain using the ossbuild script.
I started building tcl, but it stopped at some point with this error:
~tcl8.5.8/win $ ./configure --enable-shared --host=x86_64-w64-mingw32
--target=x86_64-w64-mingw32
On 8/30/2010 21:00, Chris Sutcliffe wrote:
The latest crt (at least the one in the Cygwin 'dist' release) has
conflicting exports:
csutc...@eush65 /usr/x86_64-w64-mingw32/sys-root/mingw/lib
$ x86_64-w64-mingw32-nm.exe libadvapi32.a | grep -i OpenProc
T OpenProcessToken
On 9/1/2010 15:35, Erwin Waterlander wrote:
Hi,
Are there plans to add gettext and libintl packages to mingw-w64?
Erwin Waterlander
Hi,
gettext isn't part of the toolchain, so no, we don't provide them,
unless somebody is willing to maintain it.
On 9/6/2010 05:27, İsmail Dönmez wrote:
Hi;
On Mon, Sep 6, 2010 at 12:12 AM, Kai Tietzktiet...@googlemail.com wrote:
Well, could you please try '../configure --host=x86_64-w64-mingw32
--enable-lib32 --enable-lib64 --prefix=/usr/local/mingw64'. Does this
change the behavior? At least for me
On 9/6/2010 15:11, İsmail Dönmez wrote:
Hi;
On Mon, Sep 6, 2010 at 4:03 AM, JonYjo...@users.sourceforge.net wrote:
On 9/6/2010 05:27, İsmail Dönmez wrote:
Hi;
On Mon, Sep 6, 2010 at 12:12 AM, Kai Tietzktiet...@googlemail.com
wrote:
Well, could you please try '../configure
On 9/6/2010 15:52, Mario Emmenlauer wrote:
Hi,
I'm the original author of the issue [0] that Ismail referenced. During
the last months since my report, I've repeatedly re-tried numerous times,
but failed to build the canadian cross. Actually, back then mostly the
same suggestions where
On 9/7/2010 01:34, Mario Emmenlauer wrote:
Hi,
On 09/06/2010 04:52 PM, JonY wrote:
On 9/6/2010 19:50, Mario Emmenlauer wrote:
On 9/6/2010 15:52, Mario Emmenlauer wrote:
I'm the original author of the issue [0] that Ismail referenced. During
the last months since my report, I've repeatedly
On 9/7/2010 09:37, Xiaofan Chen wrote:
On Tue, Sep 7, 2010 at 8:12 AM, JonYjo...@users.sourceforge.net wrote:
My problem is that libtool was pointing to lib64 directory in the 64bit
cross build (under Linux or 32bit Windows) cases. I need to check again
under 32bit Win 7 with TDM.
I just
On 9/8/2010 10:26, Nils Woetzel wrote:
wanted to contribute to the multilib cross compiler issue. I just
joined the list to share my solution to the problem of a failed build
for the gcc stage 2 - and hopefully the documentation/Makefile can be
adjusted.
My procedure for building the cross
On 9/8/2010 21:26, Sébastien Villemot wrote:
Hi,
Some extra information on the problem that I described in my previous post,
and
which I suspect to be a bug in MinGW-w64 for 64-bit platform.
I attach a sample testcase, which I compile with:
x86_64-w64-mingw32-gcc -g -O2 -fexceptions
On 9/9/2010 04:27, Mario Emmenlauer wrote:
Hi JonY,
On 09/07/2010 12:03 PM, JonY wrote:
On 9/7/2010 15:20, Mario Emmenlauer wrote:
On 9/7/2010 01:34, Mario Emmenlauer wrote:
On 09/06/2010 04:52 PM, JonY wrote:
On 9/6/2010 19:50, Mario Emmenlauer wrote:
On 9/6/2010 15:52, Mario Emmenlauer
On 9/9/2010 06:14, Danny Smith wrote:
may bite. Unless libstdc++ basic_string class is marked as dllimport,
_S_empty_rep is effectively hidden and different modules will have
different addresses for _S_empty_rep.
fat fingers
This can be fised by compiling libstdc++
fat fingers/
This
On 9/9/2010 08:00, Xiaofan Chen wrote:
On Tue, Sep 7, 2010 at 8:00 PM, Xiaofan Chenxiaof...@gmail.com wrote:
On Tue, Sep 7, 2010 at 10:36 AM, JonYjo...@users.sourceforge.net wrote:
Ok, to clear everything up, for non-multilib 4.6, you should only have
lib, lib64 only if you have
On 9/9/2010 12:36, Nils Woetzel wrote:
cd gcc-4.5.1-build
ln -s /mypath/x86_64-w64-mingw32 ./mingw
assuming, that you are building/configuring gcc in the folder
gcc-4.5.1-build - otherwise whatever path
I guess the howto assumes that /mypath is also the configure and build
directory, than
originally reported the error months
ago - was binutils changed that long ago?
Either way, I will try. Could this also be added to makebuildroot-test.mk?
Thanks Kai and JonY, and all the best,
Mario
I will make makebuildroot-test.mk more explicit with crt configure soon
On 9/10/2010 22:54, Xiaofan Chen wrote:
On Fri, Sep 10, 2010 at 10:16 PM, Travistravis_robin...@comcast.net wrote:
I'm playing catch up here so apologies if this has already been covered,
but..
There is an @8 on DriverEntry in the libusb0_drv.def file. I'm not exactly
sure how gcc handles
On 9/11/2010 01:22, Sébastien Villemot wrote:
Hi,
After some experimentation, it appears that my problem is much more
generic than what I had initially thought, and has no relation to
MATLAB. It seems to systematically happen when a C++ exception is thrown
by a DLL compiled using Visual C++
On 9/11/2010 21:44, Ruben Van Boxem wrote:
I have uploaded a new copy of the complete MSYS package. Changes include:
- cygtools
- console (this is not a binary, but an automated build script, probably
some sort of licensing issue)
- mintty
Ruben
Hi,
Keep up the good work and
On 9/12/2010 19:15, t66...@gmail.com wrote:
Hi,
On 12/09/2010 8:58 PM, Ruben Van Boxem wrote:
I am experimenting with building an optimized GCC 4.6, and discovered
that either
BOOT_CFLAGS=-flto BOOT_LFLAGS=-flto --enable-stage1-languages=c,lto
why not just --enable-lto ? what's the
On 9/12/2010 20:26, Ruben Van Boxem wrote:
2010/9/12 t66...@gmail.comt66...@gmail.com
Maybe you have encountered pr43467?
I noticed that one too, but they use gold, I have to use ld. It also seems
that the issue there is gold not properly reporting the error, and ld is,
but in my case ld
On 9/15/2010 19:13, Wolfgang Glas wrote:
On 2010-09-15 10:50, Ozkan Sezer wrote:
On Wed, Sep 15, 2010 at 11:33 AM, Wolfgang Glaswolfgang.g...@ev-i.at
wrote:
You might call it packagers' fate, however we have a couple of productive
packages out there, which build and run very well with
On 9/15/2010 20:56, Ruben Van Boxem wrote:
2010/9/15 Ruben Van Boxemvanboxem.ru...@gmail.com
Hi,
I now have:
working C compiler (make all-gcc) and binutils (4.5.2 snapshot, 2.20.51
snapshot respectively), both with multilib support, together with a
mingw-w64 crt build (1.0-20100914) with
On 9/17/2010 23:58, ArbolOne wrote:
Ok, folks. Apparently no one else is jumping on the Build MSYS under
64bit MSWin waggon. So, let us start with the project.
Does any of you know where to get the latest source code?
MSYS-64 Development Team
~~
Teemu stink...@yahoo.com
On 9/19/2010 08:00, Ozkan Sezer wrote:
On Sun, Sep 19, 2010 at 2:56 AM, Xiaofan Chenxiaof...@gmail.com wrote:
On Sun, Sep 19, 2010 at 7:50 AM, Ozkan Sezerseze...@gmail.com wrote:
On Sun, Sep 19, 2010 at 2:38 AM, Xiaofan Chenxiaof...@gmail.com wrote:
I think the MinGW-w64 newly included
On 9/19/2010 17:50, Ruben Van Boxem wrote:
Hi,
When I try to build GCC with ppl/cloog-ppl for the Graphite optimization
framework, bootstrap fails with undefined references in ppl_c.a to libstdc++
symbols (quite logical, because ppl is written in c++...). How can I solve
this? Is it
On 9/20/2010 21:36, Earnie wrote:
Forgot to include the list.
Original Message
Message-ID:4c976081.6090...@users.sourceforge.net
Date: Mon, 20 Sep 2010 09:24:17 -0400
From: Earnieear...@users.sourceforge.net
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1;
On 9/20/2010 22:09, Ozkan Sezer wrote:
On Mon, Sep 20, 2010 at 4:40 PM, JonYjo...@users.sourceforge.net wrote:
On 9/20/2010 21:36, Earnie wrote:
Forgot to include the list.
Original Message
Message-ID:4c976081.6090...@users.sourceforge.net
Date: Mon, 20 Sep 2010
On 9/20/2010 22:36, Earnie wrote:
Kai Tietz wrote:
2010/9/20 Earnieear...@users.sourceforge.net:
Cesar Strauss wrote:
Since MSYS is derived from Cygwin, one way to get 64-bit support
for MSYS would be to add it first to Cygwin and port it to MSYS
later. However, as this thread indicates,
On 9/21/2010 07:53, Xiaofan Chen wrote:
On Mon, Sep 20, 2010 at 10:30 PM, Ruben Van Boxem
vanboxem.ru...@gmail.com wrote:
2010/9/20 JonYjo...@users.sourceforge.net
OK, I see. I suppose some include_next tricks are in order for libusb.
Long time reader of this discussion :)
Why not just
On 9/23/2010 19:34, Earnie wrote:
Ruben Van Boxem wrote:
2010/9/22 NightStrikenightstr...@gmail.com
Can you run the testsuite? (Make -k check)
I cannot, because MSYS doesn't have the necessary tools. It
apparently only works on Cygwin, which don't have...
What is missing?
Earnie
Hi,
On 9/23/2010 21:38, NightStrike wrote:
On Tue, Sep 21, 2010 at 5:13 PM, Andy Koppeandy.ko...@gmail.com wrote:
On 21 September 2010 12:51, Earnie wrote:
Andy Koppe wrote:
Cygwin isn't strictly obliged to provide an interface to Windows.
No, but then it wouldn't really be Cyg*win* anymore. It
On 9/25/2010 11:29, Hradec wrote:
Hi there...
Its being a while we spoke about this and I end up deciding to build a linux
box to do the cross compiling, instead of OSX.
Things are way smoother now, but I'm running into trouble with ilmbase
again.
This time, I followed Doug Siemer advice
On 9/25/2010 12:58, Hradec wrote:
by the way... I'm just having a look at an old build I did on a windows box
using msys and al old mingw (3.4.5)... It did compiled susccessfuly and it
did output libHalf.dll.a and libHalf-6.dll in the /bin folder... but the
libHalf.dll.a is way smaller
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/27/2010 20:41, Simon Josefsson wrote:
Hi! I'm a new user of MinGW-w64 and would like to offer 'GNU SASL' with
URL http://www.gnu.org/software/gsasl/ to your list of projects that is
using MinGW-w64.
I have been using the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/27/2010 20:41, Simon Josefsson wrote:
Hi! I'm a new user of MinGW-w64 and would like to offer 'GNU SASL' with
URL http://www.gnu.org/software/gsasl/ to your list of projects that is
using MinGW-w64.
I have been using the
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/29/2010 16:34, Dongsheng Song wrote:
When I build libiconv NLS version, I can not run iconv.exe, which reference
a non-exist symbol 'wcsnlen', from lib32\msvcrt.def, I can see this symbol
after the following comments line:
; msvcr80.dll
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 9/30/2010 09:43, Dongsheng Song wrote:
On 2010-9-29 22:33, Kai Tietz wrote:
On Wed, Sep 29, 2010 at 5:56 PM, JonY jo...@users.sourceforge.net wrote:
As far as I know, this is not a bug. That comment means that it is
available with Windows 7
1 - 100 of 1003 matches
Mail list logo
