Re: [Mingw-w64-public] GCC stage1 lto broken?

On 12/09/2010 10:10 PM, Ruben Van Boxem wrote: > 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 Maybe you have encountered pr43467? > Please submit a full bug report, >

Re: [Mingw-w64-public] GCC stage1 lto broken?

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 diff? > > or > > --with-build-configurat

Re: [Mingw-w64-public] Header conflicts between and in recent builds of '1.0'

Hi, On 15/07/2010 9:50 PM, Kai Tietz wrote: > 2010/7/15 Kai Tietz: >> 2010/7/15 t66...@gmail.com: >>> Hi >>> On 15/07/2010 8:47 PM, Prof Brian Ripley wrote: >>>> We're working towards switching over to post-April snapshots, but we >>>> have

Re: [Mingw-w64-public] Header conflicts between and in recent builds of '1.0'

Hi On 15/07/2010 8:47 PM, Prof Brian Ripley wrote: > We're working towards switching over to post-April snapshots, but we > have 1000s of R packages to recompile. A couple of those (so far) > have thrown up header conflicts. > > Specifically for this report I used > mingw-w64-1.0-bin_i686-mingw_20

Re: [Mingw-w64-public] c++ os specific and currently gcc-4_5-branch svn

On 21/06/2010 10:43 PM, Doug Semler wrote: > On Sun, Jun 20, 2010 at 11:38 PM, t66...@gmail.com wrote: >> Hello: >> >> Yesterday I encountered a really weird / oddly gcc bug. >> AFAICT , that gcc-4_5 branch during that last past month that the C++ >>

[Mingw-w64-public] c++ os specific and currently gcc-4_5-branch svn

Hello: Yesterday I encountered a really weird / oddly gcc bug. AFAICT , that gcc-4_5 branch during that last past month that the C++ was changed. Now that the C99 implementation of C++ is in GCC 4.5 branch which indeed breaks a mingw-w64 compiler, in that aspect of C++. In the internal gcc libs

Re: [Mingw-w64-public] Underscore problem with mpfr configure

> I have a question, why does it require user to manually ranlib the > installed 32bit w64 library (shouldn't binutils or gcc invoke ranlib > after linking?) ? Sorry about the noise this isn't underscore issue. I just found out it found the wrong ranlib version, which I'll need to fix the env vari

Re: [Mingw-w64-public] Underscore problem with mpfr configure

On 17/05/2010 8:44 PM, JonY wrote: > 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 mpf

[Mingw-w64-public] Underscore problem with mpfr configure

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: libgmp not found or uses a different ABI. > Please r

Re: [Mingw-w64-public] Linkage issues

On 9/05/2010 1:55 PM, Doug Semler wrote: > I've never heard of ccache, but it seems that by the fact that > removing it from the chain gave you a good compile, i'd say the > problem is there... > > Aside from the fact that your cache should have been completely > invalidated by the new compiler, af

Re: [Mingw-w64-public] Linkage issues

On 9/05/2010 3:53 AM, Doug Semler wrote: > > If you want to see the actual compile command, either configure with > --disable-silent-rules > > or > > make V=1 ... > V=1 worked I've check the log and tried first removing ccache, re-run the command. This time file size is ok. Something must have

[Mingw-w64-public] Linkage issues

Hello: I have another problem compiling ffmpeg... Using a cross compiler gcc-4_5-branch + bin-cvs ffmpeg exe will not link. I see lots of output files having 0 byte in size. For some reason 0 byte size was written and the compiling process continued without errors until linking. 3220 2010-05-08

Re: [Mingw-w64-public] Another new leading underscore link problem

On 8/05/2010 4:31 PM, Ozkan Sezer wrote: > On Sat, May 8, 2010 at 6:19 AM, t66...@gmail.com wrote: > >> Hello: >> Further interests to the 64bit no leading underscore problem... >> I was trying to compile various library projects using gcc-4_5-branch + >> bin-

[Mingw-w64-public] Another new leading underscore link problem

Hello: Further interests to the 64bit no leading underscore problem... I was trying to compile various library projects using gcc-4_5-branch + bin-cvs and then found out there's linking problems at libxvidcore.dll Link problem also with x264.exe Where in the x264 code: common/cpu.c:extern uint32

Re: [Mingw-w64-public] Qt 4.7 branch now completely, utterly, fully and (nearly) working with mingw-w64/w32!

On 6/05/2010 10:06 PM, Fridrich Strba wrote: > Check wrap the #include windows.h in qt_windows.h by: > > #ifdef __cplusplus > extern "C" { > #endif > > ... > > #ifdef __cplusplus > } > #endif > > > ??? > Yeah that worked! > >

Re: [Mingw-w64-public] Qt 4.7 branch now completely, utterly, fully and (nearly) working with mingw-w64/w32!

On 4/05/2010 2:04 AM, Ruben Van Boxem wrote: Just to express my happiness. The WebKit part has been merged, so every part of Qt works now. To compile Qt 4.7 (development version!): Get sources from eg qt.gitorious.org/qt/qt/4.7 Get mingw-w64 from here: mingw

[Mingw-w64-public] Problem compiling qt4.7.0-tp

Hi: I'm trying to build tp and it would error out at corelib.. qt-everywhere-opensource-src-4.7.0-tp.tar.gz In file included from /lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_64-w64-mingw32/include/winnt.h:1412:0, from /lib/gcc/x86_64-w64-mingw32/4.5.1/../../../../x86_6

[Mingw-w64-public] Another compiling problem libcddb

Hello: After I have built a cross compiler + native one, of gcc-4_5-branch + binutils-cvs, in previous build problem of the gcc-releases having leading underscore. There is a problem of how mingw-w64-svn winsock2.h is currently implemented. The libcddb compile fails at: cddb_track.o In file incl

Re: [Mingw-w64-public] Build problem using a cross compiler to build a w64 native library

On 4/05/2010 11:49 PM, Ozkan Sezer wrote: > On Tue, May 4, 2010 at 4:46 PM, t66...@gmail.com wrote: > >> On 4/05/2010 11:17 PM, Ozkan Sezer wrote: >> >>> On Tue, May 4, 2010 at 4:00 PM, t66...@gmail.comwrote: >>> >>> >>>&

[Mingw-w64-public] Build problem using a cross compiler to build a w64 native library

Hello: Currently I am using the mingw-w64 SVN to build recently released GCC 4.5 4.4 series. Anyone have have problem with gcc-4.4.4 and 4.5.0 cross compiler with mingw-w64 trunk CRT and W32API running on Linux ? I use these cross compiler, but it fails at configure mpfr 2.4.2 --host=x86_64-w64

[Mingw-w64-public] DW2 support on the 4.5 branch

Hello: I have question. I have been running gcc 4.4 branch with dw2 support why can't 4.5 branch have such support? 4.4-dw2 gcc target mingw-w64 platform it runs well .. I see no reason why 4.5 fail target dw2 mingw-w64 platform. Since 4.5 have been released and development switched to 4.6, I'd h

[Mingw-w64-public] gcc-4.4 branch svn failed to compile

Hello: Anyone have build issues with current gcc-4.4 branch ? x86_64-w64-mingw32/include/wincrypt.h:1512: error: expected specifier-qualifier-list before 'CERT_DATA_BLOB' make[4]: *** [_muldi3.o] Error 1 -- Throughout i

Re: [Mingw-w64-public] GDB 7.0.1

> However I am sure I'm not the only one encountering this issue. > Perhaps I should build my own GDB binary instead, so I have more > understanding of what is going on. I built myself a gdb-7.0.1 release and it still output the warnings -

[Mingw-w64-public] gdb and 64bits

Hi Program received signal SIGFPE, Arithmetic exception. [Switching to Thread 7388.0x2a74] 0x6a599776 in __vout_AllocatePicture (p_this=0x0, p_pic=0x9e07960, i_chroma=1347835225, i_width=720, i_height=0, i_sar_num=0, i_sar_den=1) at video_output/vout_pictures.c:586 in video

Re: [Mingw-w64-public] GDB 7.0.1

Ozkan Sezer wrote: >> Also previously it was not possible to debug 64bits binary using GDB >> until this release. >> Tried gdb_20091224.tar.gz also was impossible to get any debugging info out. >> I mean previous gdb were somewhat broken and unable to debug app that crashed and got empty back

Re: [Mingw-w64-public] GDB 7.0.1

Chris Sutcliffe wrote: >> Sorry I don't but my compiler is pretty customized I guess it have >> something to do with that. >> Its a multi-lib patched gcc-4_4-branch a cross compiler, don't know if >> it something to do with the config option --with-stabs ? >> But how come you havent been able to en

Re: [Mingw-w64-public] GDB 7.0.1

> yes this bug I encounter some time ago, too. It is related to DLL files > not having any debugging information but are shown in backtrace. Here it > warns once about psymtab != symtab and code in gdb fix it afterwards. IMHO > this warning is simply pretty bogus here, or the DLL loader should

Re: [Mingw-w64-public] GDB 7.0.1

Chris Sutcliffe wrote: >>> Previously using GNU gdb 6.8 >>> There were no such annoying warnings. >>> >> Correct, there have been several posts about this on the GDB mailing >> list. AFAIK, it has something do with the pretty printers that were >> introduced in 7.x. I've sent an email to t

Re: [Mingw-w64-public] GDB 7.0.1

Chris Sutcliffe wrote: >> warning: (Internal error: pc 0xa263bff in read in psymtab, but not in >> symtab.) >> is this normal? >> > > Yes, if you do a Google for it, you'll get an explanation. > > Chris > > Previously using GNU gdb 6.8 There were no such annoying warnings. ---

Re: [Mingw-w64-public] GDB 7.0.1

t66...@gmail.com wrote: > Chris Sutcliffe wrote: >> I've uploaded 32- and 64-bit native builds of GDB for mingw-w64 built >> from the vanilla GNU GDB 7.0.1 sources: >> >> 32-bit: >> http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packag

Re: [Mingw-w64-public] GDB 7.0.1

Chris Sutcliffe wrote: > I've uploaded 32- and 64-bit native builds of GDB for mingw-w64 built > from the vanilla GNU GDB 7.0.1 sources: > > 32-bit: > http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/gdb/i686-w64-mingw32-gdb-7.0.1-4.tar.bz2/downlo

[Mingw-w64-public] Missing twalk in search.h

Hi Due to the latest change in vlc.git http://git.videolan.org/gitweb.cgi/vlc.git/?a=commitdiff;h=19adcbe5be83ce12a07d83092503c3f4a622b3b6 Now breaks build due to mingw-w64-headers crt search.h is missing twalk I found twalk inside mingw.org's mingwrt search.h implementation. Is there some reason w

[Mingw-w64-public] Another compilation problem binutils... after updated the mingw-w64-headers to svn-trunk

/home/slack/gcc/binutils-cvs/libiberty/getopt.c: In function '_getopt_internal': /home/slack/gcc/binutils-cvs/libiberty/getopt.c:683: error: called object '1' is not a function /home/slack/gcc/binutils-cvs/libiberty/getopt.c:708: error: called object '1' is not a function /home/slack/gcc/binutil

[Mingw-w64-public] gecko-sdk and x86_64-w64-mingw32 -> i686-w64-mingw32

Hello: There seems to be problem compiling and I don't know how to fix it. Is anyone having problems compile with gecko-sdk-win32-msvc-1.8.0.4.zip provided from https://developer.mozilla.org/en/Gecko_SDK#Get_the_SDK gecko-sdk/include/jni.h:1797: error: expected constructor, destructor, or type co

Re: [Mingw-w64-public] asm eror msg build crt with gcc44 branch

Ozkan Sezer wrote: Hello Can anyone tell me does gcc-4.4 branch works with multilib option with mingw-w64? Thank you No, it does not, unless you backport the necessary changes to 4.4 (which is not hard to do.) Hi, Thanks for the info, but it will be difficult for me to unless I know which comm

Re: [Mingw-w64-public] asm eror msg build crt with gcc44 branch

t66...@gmail.com wrote: JonY wrote: 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

Re: [Mingw-w64-public] asm eror msg build crt with gcc44 branch

t66...@gmail.com wrote: > t66...@gmail.com wrote: >> x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -m32 -pipe -std=gnu99 >> -Wall -Wextra -Wformat -Wstrict-aliasing -Wshadow -Wpacked -Winline >> -Wimplicit-function-declaration -Wmissing-noreturn >> -Wmissing-protot

Re: [Mingw-w64-public] asm eror msg build crt with gcc44 branch

t66...@gmail.com wrote: > x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -m32 -pipe -std=gnu99 > -Wall -Wextra -Wformat -Wstrict-aliasing -Wshadow -Wpacked -Winline > -Wimplicit-function-declaration -Wmissing-noreturn > -Wmissing-prototypes -O3 -mms-bitfields -MT > profile/

[Mingw-w64-public] asm eror msg build crt with gcc44 branch

x86_64-w64-mingw32-gcc -DHAVE_CONFIG_H -I. -m32 -pipe -std=gnu99 -Wall -Wextra -Wformat -Wstrict-aliasing -Wshadow -Wpacked -Winline -Wimplicit-function-declaration -Wmissing-noreturn -Wmissing-prototypes -O3 -mms-bitfields -MT profile/lib32_libgmon_a-profil.o -MD -MP -MF profile/.deps/lib32

Re: [Mingw-w64-public] HELP: Qt4 library 64bits mingw-w64 binary format will not run

t66...@gmail.com wrote: > Hi, > x86_64-w64-mingw32-g++ produce binary will not run. > > Runtime : libqt4_plugin.dll' (%1 is not a valid Win32 application. > (error 193)) > > plugins/libqt4_plugin.dll: file format pei-x86-64 > > > Disassembly of section .text

[Mingw-w64-public] HELP: Qt4 library 64bits mingw-w64 binary format will not run

Hi, x86_64-w64-mingw32-g++ produce binary will not run. Runtime : libqt4_plugin.dll' (%1 is not a valid Win32 application. (error 193)) plugins/libqt4_plugin.dll: file format pei-x86-64 Disassembly of section .text: 68e81000 <_pre_c_init>: 68e81000: 53 p

Re: [Mingw-w64-public] Help building a win64 native compiler from Linux

t66...@gmail.com wrote: > Kai Tietz wrote: >> 2009/8/22 Ozkan Sezer : >> Hello, >> >> I hoped this issue was solved by recent modification to fstat/stat, >> but sadly it doesn't seem so. To fix this driver bug (and it is a >> driver bug only AFAIK),

[Mingw-w64-public] Help building a win64 native compiler from Linux

Hello, I filed a bug report at gcc bug tracker http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41136 Is anyone encountering this bug and is there any possible workaround ? -- Let Crystal Reports handle the reporting - Free Cr