Re: [Mingw-w64-public] automated build gcc binary prints weird library path when running -print-search-dirs

2010-06-10 Thread Mook
On 2010-06-09 3:00 AM, Hradec wrote:
 I notice this problem when trying to build openexr package with the
 automated build mingw64...

 Notice the last path in the libraries searchpath...
 /Users/jchesney/mingw...
That is an artifact of how buildbot is set up, and shouldn't matter 
(since we use --prefix == --with-sysroot) - or at least, seemed to 
satisfy most other cases.  I'm scared of libtool, though, so maybe it 
does...

 I have no such path on my system, so I'm assuming this is a path from the
 original build that got imprinted on the binary somehow... make sense?
Yeah, and was supposed to be harmless.  I guess not?

 Its being quite annoying to deal with this since libtool keeps trying to
 check libstdc++.la on that path, which as I don't have, just fails...
And it should be finding it elsewhere... :(  Could you post some logs of 
what libtool is doing?

-- 
Mook


--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


Re: [Mingw-w64-public] Installing MSYS to use mingw-w64

2010-06-10 Thread JonY
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 build system type... i686-pc-mingw32
 checking host system type... i686-pc-mingw32

 In the post-install part I set the location to the directory where I
 extracted the 64-bit version of MinGW(on my computer it is C:\MinGW_64).
 What made me wonder is that I am seeing i686-pc-mingw32 and think that I
 should be seeing 64 at the end of this.  I'm wondering if I likely did
 something wrong or should I expect to see this?


you forgot to set --build and --host, msys usually means mingw.org gcc, 
which you are not trying to use.

you need to set host to x86_64-w64-mingw32. Build can stay i686-pc-mingw32.

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


Re: [Mingw-w64-public] Fwd: [Branch ~mingw-w64/reactos-core/ddk] Rev 645: Reintegrate header-work branch. Important changes include continued work on headers and progress ...

2010-06-10 Thread Ozkan Sezer
On Thu, Jun 10, 2010 at 1:17 PM, Ozkan Sezer seze...@gmail.com wrote:
 On Thu, Jun 10, 2010 at 5:34 AM, Dmitrijs Ledkovs
 dmitrij.led...@ubuntu.com wrote:
 FYI

 A bunch of more headers removed from the ddk/ dir of the svn repo =(


 Ugh!...  :-((
 More job for me checking all the dependencies. Ugh ugh ugh..

 --
 Ozkan


OK, committed rev. 2488 and sync'ed with their rev. 47727.
There were no new deps, just one file removed, one file added
and some files moved from ddk to psdk. (I don't mean to say
that I didn't miss anything, though..)

--
Ozkan



 -- Forwarded message --
 From:  nore...@launchpad.net
 Date: 10 June 2010 02:13
 Subject: [Branch ~mingw-w64/reactos-core/ddk] Rev 645: Reintegrate
 header-work branch. Important changes include continued work on
 headers and progress ...
 To: Dmitrijs Ledkovs dmitrij.led...@gmail.com


 
 revno: 645
 committer: akhaldi
 timestamp: Wed 2010-06-09 21:24:32 +
 message:
  Reintegrate header-work branch. Important changes include continued
 work on headers and progress on compiling for ARM.
 removed:
  compstui.h
  dciddi.h
  devioctl.h
  kcom.h
  ksdebug.h
  ksuuids.h
  lmon.h
  nettypes.h
  newdev.h
  ntddchgr.h
  ntddmou.h
  ntddstor.h
  winddi.h
  winddiui.h
  winsplp.h
  wmlib.h
 added:
  dciddi.h
  wmidata.h
 modified:
  atm.h
  csq.h
  d4drvif.h
  d4iface.h
  dderror.h
  dxapi.h
  fltsafe.h
  kbdmou.h
  miniport.h
  mountdev.h
  mountmgr.h
  ndis.h
  ndisguid.h
  ndiswan.h
  netpnp.h
  ntagp.h
  ntddk.h
  ntifs.h
  scsi.h
  srb.h
  video.h
  videoagp.h
  wdm.h
  ws2san.h


--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


Re: [Mingw-w64-public] Fwd: [Branch ~mingw-w64/reactos-core/ddk] Rev 645: Reintegrate header-work branch. Important changes include continued work on headers and progress ...

2010-06-10 Thread Henry N.
  On 10.06.2010 19:04, Ozkan Sezer wrote:
 On Thu, Jun 10, 2010 at 1:17 PM, Ozkan Sezer wrote:
 On Thu, Jun 10, 2010 at 5:34 AM, Dmitrijs Ledkovs
 dmitrij.led...@ubuntu.com  wrote:
 FYI

 A bunch of more headers removed from the ddk/ dir of the svn repo =(

 Ugh!...  :-((
 More job for me checking all the dependencies. Ugh ugh ugh..

 --
 Ozkan

 OK, committed rev. 2488 and sync'ed with their rev. 47727.
 There were no new deps, just one file removed, one file added
 and some files moved from ddk to psdk. (I don't mean to say
 that I didn't miss anything, though..)

Why not use directories include/ddk and include/psdk as they are? Why 
needs to merge into one directory?

-- 
Henry N.


--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


Re: [Mingw-w64-public] Problem with MSYS on 64-bit

2010-06-10 Thread Doug Semler
On Thu, Jun 10, 2010 at 3:25 PM, Chris Saunders e...@mountaincable.net wrote:
 I have installed MinGW 64-bit and am attempting to get MSYS to work with
 it.  I attempted to configure GMP-5.0.1.  Here is the command line I used to
 run configure and the first few lines of output (My OS is Windows 7
 64-bit.):

 $ ./configure --disable-shared --enable-alloca=no --host=x86_64-w64-mingw32
 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.
 checking build system type... i686-pc-mingw32
 checking host system type... x86_64-w64-mingw32

 I also ran make and it appeared to me to run successfully.  I then ran make
 check and it reported one error.  I'm guessing that the problem is that the
 build system type and host system type are different.  Can someone tell me
 if this is the likely source of the problem and what I could do about it?

 Regards
 Chris Saunders

What, exactly, was the error with make check???  Without knowing that,
I couldn't tell you what the problem could possibly be...a bug in gmp,
a bug in the runtime, a bug in the compiler or a bug between the
keyboard and the chair :-)

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


[Mingw-w64-public] Problem with MSYS on 64-bit

2010-06-10 Thread Chris Saunders
I have installed MinGW 64-bit and am attempting to get MSYS to work with it.  I 
attempted to configure GMP-5.0.1.  Here is the command line I used to run 
configure and the first few lines of output (My OS is Windows 7 64-bit.):

$ ./configure --disable-shared --enable-alloca=no --host=x86_64-w64-mingw32
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. 

checking build system type... i686-pc-mingw32

checking host system type... x86_64-w64-mingw32

I also ran make and it appeared to me to run successfully.  I then ran make 
check and it reported one error.  I'm guessing that the problem is that the 
build system type and host system type are different.  Can someone tell me if 
this is the likely source of the problem and what I could do about it?

Regards
Chris Saunders--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


Re: [Mingw-w64-public] Problem with MSYS on 64-bit

2010-06-10 Thread Doug Semler
On Thu, Jun 10, 2010 at 4:10 PM, Chris Saunders e...@mountaincable.net wrote:
 The error was:

 n = 97327602995864283868534915224192610...(cut this because it was very
 long)

 n was destroyed, but perfpow_p still believes n is a perfect power

 This application has requested the Runtime to terminate it in an unusual
 way.
 Please contact the application's support team for more information.
 FAIL: t-perfpow.exe

 I had intended to include that in the message but forgot.  Sorry.

 Regards
 Chris Saunders


That's what I figured.  Note we are a long long ABI.  Soo

from http://gmplib.org/
quote
There are spurious test failures with mpz/t-perfpow.c when using an
ABI where GMP uses long long for internal computations. Examples of
such ABIs are MIPS n32, HPUX 2.0n, and PowerPC mode32.
/quote

(Note that this is fixed on the mercurial 5.0 branch since February)

Patch:

# HG changeset patch
# User Torbjorn Granlund t...@gmplib.org
# Date 1267122532 -3600
# Node ID 794410151f5f966bcb5c3489b6441614990efe7c
# Parent  948660e2e56d9cfaae035082b8fd473985505fb6
Fix a test case to work for long long limbs.

diff -r 948660e2e56d -r 794410151f5f ChangeLog
--- a/ChangeLog Thu Feb 25 16:08:21 2010 +0100
+++ b/ChangeLog Thu Feb 25 19:28:52 2010 +0100
@@ -1,5 +1,8 @@
 2010-02-25  Torbjorn Granlund  t...@gmplib.org

+   * tests/mpz/t-perfpow.c (check_random): Use mp_limb_t type for limb
+   variables.
+
* tests/mpn/t-div.c: Cast a switch index to placate HP's cc.
* tests/mpn/t-bdiv.c: Likewise.

diff -r 948660e2e56d -r 794410151f5f tests/mpz/t-perfpow.c
--- a/tests/mpz/t-perfpow.c Thu Feb 25 16:08:21 2010 +0100
+++ b/tests/mpz/t-perfpow.c Thu Feb 25 19:28:52 2010 +0100
@@ -2,7 +2,7 @@

Contributed to the GNU project by Torbjorn Granlund and Martin Boij.

-Copyright 2008, 2009 Free Software Foundation, Inc.
+Copyright 2008, 2009, 2010 Free Software Foundation, Inc.

 This file is part of the GNU MP Library.

@@ -109,7 +109,8 @@
 {
   mpz_t n, np, temp, primes[NRP];
   int i, j, k, unique, destroy, res;
-  unsigned long int nrprimes, primebits, g, exp[NRP], e;
+  unsigned long int nrprimes, primebits;
+  mp_limb_t g, exp[NRP], e;
   gmp_randstate_ptr rands;

   rands = RANDS;

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


Re: [Mingw-w64-public] Problem with MSYS on 64-bit

2010-06-10 Thread Chris Saunders
First, thanks very much for the reply Doug.  I don't know what the 
mercurial 5.0 branch is.  Could I ask for an explenation?  Also, does your 
reply mean that I can ignore the error I got from make check?  I used MSYS 
to build MPFR using 
./configure --disable-shared --host=x86_64-w64-mingw32 
--with-gmp-build=/home/chris/gmp-5.0.1 
and make check ran with no errors.

Regards
Chris Saunders

--
From: Doug Semler dougsem...@gmail.com
Sent: Thursday, June 10, 2010 4:21 PM
To: Chris Saunders e...@mountaincable.net
Cc: mingw-w64-public@lists.sourceforge.net
Subject: Re: [Mingw-w64-public] Problem with MSYS on 64-bit

 On Thu, Jun 10, 2010 at 4:10 PM, Chris Saunders e...@mountaincable.net 
 wrote:
 The error was:

 n = 97327602995864283868534915224192610...(cut this because it was very
 long)

 n was destroyed, but perfpow_p still believes n is a perfect power

 This application has requested the Runtime to terminate it in an unusual
 way.
 Please contact the application's support team for more information.
 FAIL: t-perfpow.exe

 I had intended to include that in the message but forgot.  Sorry.

 Regards
 Chris Saunders


 That's what I figured.  Note we are a long long ABI.  Soo

 from http://gmplib.org/
 quote
 There are spurious test failures with mpz/t-perfpow.c when using an
 ABI where GMP uses long long for internal computations. Examples of
 such ABIs are MIPS n32, HPUX 2.0n, and PowerPC mode32.
 /quote

 (Note that this is fixed on the mercurial 5.0 branch since February)

 Patch:

 # HG changeset patch
 # User Torbjorn Granlund t...@gmplib.org
 # Date 1267122532 -3600
 # Node ID 794410151f5f966bcb5c3489b6441614990efe7c
 # Parent  948660e2e56d9cfaae035082b8fd473985505fb6
 Fix a test case to work for long long limbs.

 diff -r 948660e2e56d -r 794410151f5f ChangeLog
 --- a/ChangeLog Thu Feb 25 16:08:21 2010 +0100
 +++ b/ChangeLog Thu Feb 25 19:28:52 2010 +0100
 @@ -1,5 +1,8 @@
 2010-02-25  Torbjorn Granlund  t...@gmplib.org

 + * tests/mpz/t-perfpow.c (check_random): Use mp_limb_t type for limb
 + variables.
 +
  * tests/mpn/t-div.c: Cast a switch index to placate HP's cc.
  * tests/mpn/t-bdiv.c: Likewise.

 diff -r 948660e2e56d -r 794410151f5f tests/mpz/t-perfpow.c
 --- a/tests/mpz/t-perfpow.c Thu Feb 25 16:08:21 2010 +0100
 +++ b/tests/mpz/t-perfpow.c Thu Feb 25 19:28:52 2010 +0100
 @@ -2,7 +2,7 @@

Contributed to the GNU project by Torbjorn Granlund and Martin Boij.

 -Copyright 2008, 2009 Free Software Foundation, Inc.
 +Copyright 2008, 2009, 2010 Free Software Foundation, Inc.

 This file is part of the GNU MP Library.

 @@ -109,7 +109,8 @@
 {
   mpz_t n, np, temp, primes[NRP];
   int i, j, k, unique, destroy, res;
 -  unsigned long int nrprimes, primebits, g, exp[NRP], e;
 +  unsigned long int nrprimes, primebits;
 +  mp_limb_t g, exp[NRP], e;
   gmp_randstate_ptr rands;

   rands = RANDS; 


--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


Re: [Mingw-w64-public] Fwd: [Branch ~mingw-w64/reactos-core/ddk] Rev 645: Reintegrate header-work branch. Important changes include continued work on headers and progress ...

2010-06-10 Thread Ozkan Sezer
On Thu, Jun 10, 2010 at 10:10 PM, Henry N. henrynmail-mi...@yahoo.de wrote:
  On 10.06.2010 19:04, Ozkan Sezer wrote:
 On Thu, Jun 10, 2010 at 1:17 PM, Ozkan Sezer wrote:
 On Thu, Jun 10, 2010 at 5:34 AM, Dmitrijs Ledkovs
 dmitrij.led...@ubuntu.com  wrote:
 FYI

 A bunch of more headers removed from the ddk/ dir of the svn repo =(

 Ugh!...  :-((
 More job for me checking all the dependencies. Ugh ugh ugh..

 --
 Ozkan

 OK, committed rev. 2488 and sync'ed with their rev. 47727.
 There were no new deps, just one file removed, one file added
 and some files moved from ddk to psdk. (I don't mean to say
 that I didn't miss anything, though..)

 Why not use directories include/ddk and include/psdk as they are? Why
 needs to merge into one directory?

 --
 Henry N.

Because while their psdk and our includes aren't exactly the same as
each other, there are many duplicated files in each.

--
ThinkGeek and WIRED's GeekDad team up for the Ultimate 
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the 
lucky parental unit.  See the prize list and enter to win: 
http://p.sf.net/sfu/thinkgeek-promo
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public