Re: [Mingw-w64-public] Cannot #include
On 5/23/08, Matthew Bentham <[EMAIL PROTECTED]> wrote: > My experience with the binary builds from mingw64 SourceForge has also been > that they suffer from the Vista access() problem, as we discussed on this > mailing list on Feb 24th 2008. I've included my notes from the time > (discussing the state of GCC bug 33281 with FXCoudert and NightStrike) below. > Unfortunately I haven't had time to look at it myself since then, I use a > compiler that I built from source myself and explicitly define > __USE_MINGW_ACCESS when doing so. Matthew, Please try the latest build dated 0528 for the native toolchain, and make sure that your version of Vista is at SP1 (Thanks, Sisyphus!) Please let me know if your problems go away (well, not all of your problems... but any relating to mingw-w64!) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Cannot #include
On 6/2/08, Sisyphus <[EMAIL PROTECTED]> wrote: > > - Original Message - From: "NightStrike" <[EMAIL PROTECTED]> > To: "Sisyphus" <[EMAIL PROTECTED]> > Cc: > Sent: Tuesday, June 03, 2008 1:05 AM > Subject: Re: [Mingw-w64-public] Cannot #include > . > . > > I'm running with SP1 > > installed and all the recent updates. > > > > Windows Update installs updates every day - but doesn't install SP1. > Installing SP1 seems to have fixed the problem ... which is, no doubt, a > relief to *both* of us. (At least that test program builds and runs > correctly.) > > Thanks, NightStrike. A relief indeed! I had no idea whatsoever what else to suggest! I guess at this point I should put somewhere on the site that Vista support requires SP1. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Compiling OpenSSL with mingw-w64
> - I added a "mingw64" line to Configure and (think I) told it to use > .exe > extension for compiling. Nothing surprising here, I think. Note that > you currently need to "Configure mingw64 no-asm no-hw". IIUC, the current position on naming is that mingw64 shouldn't be used, but rather the full triplet x86_64-pc-mingw or, as a simpler name, mingw-w64. FX -- François-Xavier Coudert http://www.homepages.ucl.ac.uk/~uccafco/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Compiling OpenSSL with mingw-w64
Hi, I just tried to compile OpenSSL-0.9.8h with mingw-w64 (see http://sourceforge.net/projects/mingw-w64/) and needed a couple of changes to the source code (see attached patch). Some notes: - I added a "mingw64" line to Configure and (think I) told it to use .exe extension for compiling. Nothing surprising here, I think. Note that you currently need to "Configure mingw64 no-asm no-hw". - windows.h apparently includes wincrypt.h (no idea whether that's specific to that compiler, but it seems so ...), so I needed to #undefine a couple of names messed up by wincrypt.h (patches to rand.h, x509.h and e_os.h). - It's using a very recent snapshot of gcc, so there also is the problem in e_os2.h, that has already been reported for gcc-4.3: the compiler complains about the same variable being declared as both extern and static - so I changed that to use static both times - but I'm not really sure what's the correct thing to do here. Regards, Stefan openssl-h.patch Description: Binary data - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Compiling OpenSSL with mingw-w64
Hi Stefan, FX,
> > - I added a "mingw64" line to Configure and (think I) told it to use
> > .exe
> > extension for compiling. Nothing surprising here, I think. Note that
> > you currently need to "Configure mingw64 no-asm no-hw".
>
> IIUC, the current position on naming is that mingw64 shouldn't be
> used, but rather the full triplet x86_64-pc-mingw or, as a simpler
> name, mingw-w64.
The full host triplet is x86_64-*-mingw32, so a check for x86_64-*-mingw*
is fine, too. The postfix 32 to the triplet name is necessary, because not
all names in gcc configure are modified until now. Otherwise you may loose
some configuration options.
Stefan, thanks for your contribution. I will comment soon on it.
Cheers,
Kai
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Compiling OpenSSL with mingw-w64
Hi Stefan,
>Hi,
>
> I just tried to compile OpenSSL-0.9.8h with mingw-w64 (see
> http://sourceforge.net/projects/mingw-w64/) and needed a couple
> of changes to the source code (see attached patch).
>
> Some notes:
> - I added a "mingw64" line to Configure and (think I) told it to use
> .exe
> extension for compiling. Nothing surprising here, I think. Note that
> you currently need to "Configure mingw64 no-asm no-hw".
>
> - windows.h apparently includes wincrypt.h (no idea whether that's
> specific to that compiler, but it seems so ...), so I needed to
> #undefine a couple of names messed up by wincrypt.h
> (patches to rand.h, x509.h and e_os.h).
>
> - It's using a very recent snapshot of gcc, so there also is the
> problem in e_os2.h, that has already been reported for
> gcc-4.3: the compiler complains about the same variable
> being declared as both extern and static - so I changed that
> to use static both times - but I'm not really sure what's the
> correct thing to do here.
The cygwin specific options - like "-mno-cygwin" - in the "mingw64" line
of configure are not necessary. There is no cygwin for 64-bit for now
IIRC.
Thank you for porting.
Regards,
Kai
| (\_/) This is Bunny. Copy and paste Bunny
| (='.'=) into your signature to help him gain
| (")_(") world domination.
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Cannot #include
- Original Message > From: NightStrike <[EMAIL PROTECTED]> > To: Matthew Bentham <[EMAIL PROTECTED]> > Cc: mingw-w64-public@lists.sourceforge.net > Sent: Tuesday, June 3, 2008 8:06:13 AM > Subject: Re: [Mingw-w64-public] Cannot #include > > On 5/23/08, Matthew Bentham wrote: > > My experience with the binary builds from mingw64 SourceForge has also been > that they suffer from the Vista access() problem, as we discussed on this > mailing list on Feb 24th 2008. I've included my notes from the time > (discussing > the state of GCC bug 33281 with FXCoudert and NightStrike) below. > Unfortunately > I haven't had time to look at it myself since then, I use a compiler that I > built from source myself and explicitly define __USE_MINGW_ACCESS when doing > so. > > > > Matthew, > > Please try the latest build dated 0528 for the native toolchain, and > make sure that your version of Vista is at SP1 (Thanks, Sisyphus!) > Please let me know if your problems go away (well, not all of your > problems... but any relating to mingw-w64!) Yep, works fine now. Very mysterious! I wonder what changed in SP1, and I wonder what I was doing differently in my build that made it work pre SP1. Maybe the access() problem doesn't even exist in SP1. Thanks all, Matthew - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Compiling OpenSSL with mingw-w 64
Hi, In reply to various mails, let me add some comments: > > - I added a "mingw64" line to Configure and (think I) told it to use > > .exe > > extension for compiling. Nothing surprising here, I think. Note that > > you currently need to "Configure mingw64 no-asm no-hw". Note that OpenSSL's "Configure" is not autoconf-based, so the usual triplets are irrelevant (and not used for the other platforms either). > > - windows.h apparently includes wincrypt.h (no idea whether that's > > specific to that compiler, but it seems so ...), so I needed to > > #undefine a couple of names messed up by wincrypt.h > > (patches to rand.h, x509.h and e_os.h). OpenSSL developpers seem to rather consider this a mingw_w64 bug, at least I got one reply on that list indicating that MS samples normally explicitly include both headers... > The cygwin specific options - like "-mno-cygwin" - in the "mingw64" > line of configure are not necessary. There is no cygwin for 64-bit for > now IIRC. I just tried to change the original "mingw" (for 32 bit) configuration line as little as possible. But no, I didn't find any other gcc based project targetting Win64 either. BTW, what platform exactly are you targetting: x86_64 only, or (T)itanic (aka IA64) as well? In the longer run, I mean. ATM it's appears to obviously be x86_64 only. > Thank you for porting. Well that's a bit of an exaggeration - I only made it compile, I currently have no idea whether or how well it works - that's the nice thing about a cross-compiler... ;-) At least, it's not using existing assembly code, which certainly is not so good, but once it does at least compile, that might give other people (more fluent with assembler and it's error messages) a better starting point. Regards, Stefan - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Cannot #include
- Original Message - From: "Matthew Bentham" <[EMAIL PROTECTED]> . . > Maybe the access() problem doesn't even exist in SP1. Oh, shit ... I think that's right !! Before installing SP1, with a certain MinGW32 installation, I got: --- C:\_64\C>\strawberry\c\bin\gcc -o try.exe try.c gcc: installation problem, cannot exec `cc1': No such file or directory C:\_64\C> --- Having now installed SP1, using the very same MinGW32 installation, I get: --- C:\_64\C>\strawberry\c\bin\gcc -o try.exe try.c C:\_64\C>try 8 C:\_64\C> --- That's without having changed either that MinGW32 installation or C:\_64\C\try.c in any way. Cheers, Rob - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Compiling OpenSSL with mingw-w64
On 6/3/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi, > > In reply to various mails, let me add some comments: > > > > - I added a "mingw64" line to Configure and (think I) told it to use > > > .exe > > > extension for compiling. Nothing surprising here, I think. Note that > > > you currently need to "Configure mingw64 no-asm no-hw". > > Note that OpenSSL's "Configure" is not autoconf-based, so the usual > triplets are irrelevant (and not used for the other platforms either). The reason that you have to use the entire target triplet is that that is how the executables are named. The executable for the cross compiler under any host is "x86_64-pc-mingw32-gcc". Eventually, if we ever get around to dropping the 32, it will be just "x86_64-pc-mingw-gcc". So presumably you are configuring for the "target triplet" system, which will translate into the canonicalized name of the executable. > > > - windows.h apparently includes wincrypt.h (no idea whether that's > > > specific to that compiler, but it seems so ...), so I needed to > > > #undefine a couple of names messed up by wincrypt.h > > > (patches to rand.h, x509.h and e_os.h). > > OpenSSL developpers seem to rather consider this a mingw_w64 > bug, at least I got one reply on that list indicating that MS samples > normally explicitly include both headers... > > > The cygwin specific options - like "-mno-cygwin" - in the "mingw64" > > line of configure are not necessary. There is no cygwin for 64-bit for > > now IIRC. > > I just tried to change the original "mingw" (for 32 bit) configuration > line as little as possible. For mingw, you don't need those options either. You can change it for both. > But no, I didn't find any other gcc based project > targetting Win64 either. BTW, what platform exactly are you targetting: > x86_64 only, or (T)itanic (aka IA64) as well? In the longer run, I > mean. ATM it's appears to obviously be x86_64 only. If we can get some IA64 hardware, maybe we can create a roadmap. Know any donors? > > Thank you for porting. > > Well that's a bit of an exaggeration - I only made it compile, I > currently have no idea whether or how well it works - that's the nice thing > about > a cross-compiler... ;-) > At least, it's not using existing assembly code, which certainly is not > so good, but once it does at least compile, that might give other people > (more fluent with assembler and it's error messages) a better starting point. You're handling the first, and very important, step, so don't sell yourself short! - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Sources for compiler?
NightStrike wrote: > > Thats some damn good progress. Thanks. > > Thank Kai, not me. I just talk a lot -- he does all the work :) Thanks Kai! Excellent work. Cheers, Erik -- - Erik de Castro Lopo - "Web (hosting), security and high-performance computing are the three areas where Linux has more strength." -- Bob Muglia, senior VP in charge of Windows Server development. http://news.com.com/Microsoft+targets+Apache+Web+server/2100-1010_3-5735805.html - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
