[Mingw-w64-public] fpsetenv broke?

[Doug Semler]

I honestly can't figure out the logic behind the implementation of
fesetnenv.  Why is an sse2 instruction outside of the guard?  In addition,
why is there a (retrieve parameters) call to the fpu that reenables all the
exception masks? Kai was the last person to make the changefour years
ago...so I'm sure there are things that were forgotten...butAll I know
is right now is that the call to fesetenv does not restore the fpu to the
state passed.  Unsure as to the correct solution but the following code
"seems" to work (and my fpu knowledge kinda sucks so I *know* I'm missing
something)basically it's a change from getting the floating point to
just setting it (and the sse control register)...a reverse of what the
fegetenv function does. Yes I know this isn't a patch...it's
...mingw-crt/misc/fesetenv.c

(what is confusing me is can someone quickly remind me of the __asm__ syntax
with the float stack args?)


  else
{
  fenv_t env = *envp;
  int _mxcsr;
  __asm__ volatile ("fldenv %0" : : "m" (*envp)
: "st", "st(1)", "st(2)", "st(3)", "st(4)",
"st(5)", "st(6)", "st(7)");
  if (__mingw_has_sse())
{
   _mxcsr = (unsigned int)((envp->__unused0 & 0x) << 16);
   _mxcsr |= (unsigned int)(envp->__unused1 & 0x);
   __asm__ volatile ("ldmxcsr %0" : : "m" (*&_mxcsr));
}
}



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] FW: Section sizes too big in object files (possible bug?)

[Doug Semler]

Ah, it was -malign-data, not -falign-data   no wonder I didn't find it.  DUH

-Original Message-
From: Liu Hao [mailto:lh_mo...@126.com] 
Sent: Wednesday, August 02, 2017 11:54 AM
To: mingw-w64-public@lists.sourceforge.net; Madalinski Piotr

Subject: Re: [Mingw-w64-public] FW: Section sizes too big in object files
(possible bug?)

On 2017/8/2 19:42, Madalinski Piotr wrote:
> Hi all,
> 
> I'm having trouble with getting correct section sizes under MinGW.
> The example below demonstrates the issue:
> 
> (... abridgement ...)
> 
> Adding align(1) attribute to the data definition is a workaround, that
fixes the problem, but due to external factors I want to avoid adding it, if
possible.
> This behavior looks as a bug to me, but I can't say for sure.
> Anyhow - is there some other (than the align(1) attribute) approach that
this behavior can be changed? Compiler option maybe?
> 

`-malign-data=abi` shall fix the problem by minimizing the alignment
requirement:

```plaintext
E:\Desktop>gcc test.c -Wl,-s && objdump -h a.exe | grep -F test_sec
grep: warning: GREP_OPTIONS is deprecated; please use an alias or script
   2 test_sec  0040  00404000  00404000  1c00  2**5

E:\Desktop>gcc test.c -Wl,-s -malign-data=abi && objdump -h a.exe | grep -F
test_sec
grep: warning: GREP_OPTIONS is deprecated; please use an alias or script
   2 test_sec  0024  00404000  00404000  1c00  2**2

```

Reference: 
https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc/x86-Options.html#x86-Options

--
Best regards,
LH_Mouse



--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public


--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] FW: Section sizes too big in object files (possible bug?)

[Doug Semler]

If I remember correctly, the default alignment for structure starts on a 32
byte boundary, to help prevent data member misalignments with SSE type
instructions.  What you are seeing is the result of padding. I add an
integer in the same section
__attribute__((section("test_section"))) test_struct_t test_struct;
__attribute__((section("test_section"))) int a;
__attribute__((section("test_section"))) int b;

, and you get the following from objdump:
[ 20](sec  4)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x
test_struct
[ 21](sec  4)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0024 a
[ 22](sec  4)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0028 b

With the section size of 0x40.  In fact, when adding another copy of the
test structure after a, you will get the second one starting at 
0x40, with a section size of 0x80.  This is no optimization, by the way.

NOTE: this is without ANY optimization flags.  If you compile with -O1, you
get
[ 20](sec  7)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x b
[ 21](sec  7)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0004 a
[ 22](sec  7)(fl 0x00)(ty   0)(scl   2) (nx 0) 0x0020
test_struct

With a section size of 0x60 (section padded to the 32 byte boundary -- but
honestly I don't know why the padding is to the 64 byte boundary above in
the first case, and only the 32 byte boundary in the second case)

Adding another copy of the structure, can cause different padding, different
rearrangements, depending upon the options. 

You can force the alignment of something to a particular boundary with
__attribute__((aligned(n))), but that does introduce the potential to cause
misalignment with structure members.

Please note the above offsets are just the result of the gcc -c command,
just the object file.  Doesn't even address the linker relocations and other
such things in the final executable (because of optimizations of
variable/section removals, etc).  But the flag for the ordering is
-fno-toplevel-reorder at the higher optimization levels.  Note none of the
-falign flags actually will do anything with data sections, if I remember
correctly.

Honestly, if your linker scripts cannot handle alignments and padding
introduced by a compiler, I would say that your *linker* script has the
issue and needs to be written so that things are aligned kept aligned
properly.  I would *never* assume section layout or alignments *especially*
on a windows system (e.g. assuming that because the variable b is defined
after a is a HUGE mistake, because obviously the compiler rearranged them).
(note, it's been a little since I have futzed with linker scripts, but I do
know that you can specify at least .ALIGN in sections, if not padding)

-Original Message-
From: Madalinski Piotr [mailto:piotr.madalin...@zf.com] 
Sent: Wednesday, August 02, 2017 7:43 AM
To: mingw-w64-public@lists.sourceforge.net
Subject: [Mingw-w64-public] FW: Section sizes too big in object files
(possible bug?)

Hi all,

I'm having trouble with getting correct section sizes under MinGW.
The example below demonstrates the issue:

test.c:

#include 
#include 

typedef struct
{
uint16_t a;
uint16_t b[16];
uint8_t  c[2];
} test_struct_t;

__attribute__((section("test_section")))
test_struct_t test_struct;

int main(int argc, char** argv) {
printf("size:%x, sizeof(test_struct_t)); }

After compiling under MinGW [gcc.exe (Rev2, Built by MSYS2 project) 7.1.0]
the size reported by the program are 0x24 which is correct, however objdump
reports the section size to be 0x40 (which is a problem for my linker
script)

I did compile the same program under both Clang/Win32 and GCC/Linux and the
section has correct size of 0x24 in both cases.

Adding align(1) attribute to the data definition is a workaround, that fixes
the problem, but due to external factors I want to avoid adding it, if
possible.
This behavior looks as a bug to me, but I can't say for sure.
Anyhow - is there some other (than the align(1) attribute) approach that
this behavior can be changed? Compiler option maybe?


Pozdrawiam / Kind Regards
Piotr Madaliński
Software Engineer
ZF TRW
Active & Passive Safety Technology
TRW Polska, Czestochowa Engineering Center ul. Rolnicza 33, 42-200
Czestochowa / Poland Phone +48 34 343 4864
piotr.madalin...@zf.com


TRW Polska Sp. z o.o., ul. Rolnicza 33, 42-200 Czestochowa, Sad Rejonowy w
Czestochowie, KRS nr 077409 NIP nr 573-010-52-34, kapital zakladowy:
79.581.975 PLN

TRW Polska Sp. z o.o. Rolnicza 33 Str., 42-200 Czestochowa, Poland District
Court for Czestochowa, KRS no. 077409, tax identification no. NIP
573-010-52-34, share capital: 79.581.975 PLN

Niniejsza wiadomosc moze zawierac informacje poufne oraz/lub prawnie
chronione, przeznaczone do wylacznego uzytku adresata. Jesli nie jestescie
Panstwo adresatem przesylki lub jesli otrzymaliscie ja Panstwo omylkowo,
prosimy o bezzwloczne skontaktowanie sie z nadawca i usuniecie tej

Re: [Mingw-w64-public] Extending mingw-w64's dirent.h/c functionality

[Doug Semler]

On Thursday, July 22, 2010 09:44:08 Ozkan Sezer wrote:
 On Thu, Jul 22, 2010 at 12:29 PM, Ruben Van Boxem
 
 vanboxem.ru...@gmail.com wrote:
  Hi,
  
  Would it be feasable to provide an extension to the POSIX dirent.h
  functionality? I found a small patch in some compatibility layer (in git
  source) that adds d_type to the DIR structure, which is currently
  missing. I discovered this when testing the POSIX code I was writing to
  list all files in a directory recursively. I thought mingw has a small
  compat layer to POSIX, but didn't realise it was this shallow.
  
  The link is: http://marc.info/?l=gitm=124386152125913
  
  It would be great to have this included in the readdir functionality of
  mingw-w64.
  
  Ruben
 
 The functionality would be nice, yes, but new member in the DIR
 structure means api change  breaking backwards compatibility.
 I don't know how the admins would react to that.
 

It would be nice.  However:

1) d_type is a POSIX extension, which means that it isn't defined by POSIX to 
begin with, and may not be available to begin with.  Considering that the 
Linux man pages even state that not all file system types support the d_type 
field anyway, the application may have to provide fallbacks to begin with 
because they would *have* to support the DT_UNKNOWN on those systems that do 
have the d_type field.
2) I'm not sure the licensing of the patch referenced (I didn't look at it 
except to see what it applied to).  We'd have to do our own stuff.
3) The only file types that we would support are DT_REG and DT_DIR, which means 
I really don't see any high priority in this when the application can do the 
simple check for GetFileAttributes[Ex](dirent.d_name)  
FILE_ATTRIBUTE_DIRECTORY on the result of the readdir (which, note, I don't 
think works directly on network shares themselves, you need to specify a 
subfolder on the share).

By the way, I personally have no problem in *adding* structure members to our 
link time libraries that are not DLLs (libmingwex.a, etc), PROVIDED that we 
also provide some sort of feature test macro that would allow applications to 
determine whether the feature is available in the runtime against which they 
are linking...(the reason I say this is that the headers and libraries must 
match, so all the structures at compile time match --- if we provided runtime 
DLLs, that would definitely be a different story.)

Doug

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] QtCreator and mingw-w64 gdb

[Doug Semler]

On Saturday, July 10, 2010, Ruben Van Boxem vanboxem.ru...@gmail.com wrote:
 Hi,

 I have always had trouble with gdb and QtCreator using mingw-w64. Don't know 
 if it's a QtCreator issue or just something on my system, but I'd like of 
 someone else confirmed this for me. Every time I click debug application 
 (lower left corner), a cmd window pops up, and nothing happens.

 You can use the QtCreator package from External binary packages. It is x64, 
 so you'll need x64 Windows to test.

 Problem is, you either need to import a CMake project or create a new qmake 
 project :s, which means building Qt. I'd opt for the first, as it saves (a 
 lot) of time. If you have 32-bit Qt and 32-bit mingw-w64, please try as well

 Thanks! Please don't feel obligated, I'm just trying to get some confirmation 
 here :)

 PS: if it's a QtCreator problem, I'll be reporting it as a bug.


note. This is a WAG because I don't have experience with qtcreator but

*everything* that is desired to be debugged must be the same
architecture.  The app, gdb (so it can attach) and most likely
qtcreator itself

my guess is that qtcreator injects a debugbreakprocess into the
running process which means that it needs to be the same arch.  You
can't debugbreakprocess a 32 bit app from 64bit and vice versa.  You
could be seeing a side effect of this failing.

(one more thing...if this is already the case that everything is the
same we have an issue in 64 bit gcc compiled apps with respect to
setting up the stack unwind info that is also used during debugging
(mingw 64 doesn't yet do this).   This causes a debugbreakprocess et
al to not work unless the debugger is already attached to the process.

Hope this helps a bit in your hunt

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Backporting multilib support to GCC 4.4.x tree

[Doug Semler]

On Wed, Jun 30, 2010 at 3:32 PM, Paarvai Naai opensource3...@gmail.com wrote:
 Hi all,

 I am trying to build a mingw-w64 cross-compiler using the instructions
 outlined on the web.

 Originally I was successful in building a multilib cross-compiler
 using GCC 4.5.0, but now I want to backtrack to GCC 4.4.4.  This is
 because I found an optimization bug in GCC 4.5.0 that results in wrong
 code generation, making me now weary of using it.  Alas, it appears
 that GCC 4.5.0 isn't as stable as one might think...

Have you filed a bugzilla report for gcc against this bug?  If it is
an optimization wrong code bug, then it probably exists for other
targets besides mingw32.  I'd be curious to see whether it is actually
a bug in the compiler or a bug in the code itself.  For example, a
common occurrence in migrating to compiling with gcc 4.5+ is better
optimizations of pointer aliasing handling such as the following:

#include stdio.h

double s = 123;
int main()
{
  unsigned int* pc = (unsigned int*)s;
  *pc = 43;
  printf(%f, s);
  return 0;
}

Optimization is free to print 123.0 (seemingly unexpectedly) in
these cases.  While this may seem like a bug in gcc, it's actually a
bug in the user's code, exposed by the optimizer.



I personally wouldn't do a mulitlib compiler with 4.4 series, but just
have two compilers, one that targets i686-w64-mingw32 and one that
targets x86_64-w64-mingw32.

In fact, even with the 4.5 and 4.6 series, multilib requires a bit of
work to ensure that the installed DLLs are correctly placed on the
build system.  This doesn't even take into consideration placement of
the runtime libraries on the end user's system.

--
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] can't compile ffmpeg 0.6 with mingw-w64-bin_i686-mingw_20100619

[Doug Semler]

On Wed, Jun 23, 2010 at 1:38 PM, Kolb, Jeremy jk...@wsi.com wrote:
 I keep getting compile errors



 $ ./configure --enable-shared --disable-static --enable-cross-compile
 --enable-cross-compile --cross-prefix=x86_64-w64-mingw32- --arch=amd64
 --target-os=mingw32 --enable-w32threads



 make

 ...



 libswscale/swscale_template.c: In function 'sws_init_swScale_3DNow':

 libswscale/swscale_template.c:2965:44: warning: assignment from incompatible
 poi

 nter type [enabled by default]

 libswscale/swscale_template.c:2980:44: warning: assignment from incompatible
 poi

 nter type [enabled by default]

 libswscale/swscale_template.c:3025:40: warning: assignment from incompatible
 poi

 nter type [enabled by default]

 libswscale/swscale.c: In function 'sws_scale':

 libswscale/swscale.c:1925:19: warning: to be safe all intermediate pointers
 in c

 ast from 'uint8_t **' to 'const uint8_t **' must be 'const' qualified
 [-Wcast-qu

 al]

 libswscale/swscale.c:1948:19: warning: to be safe all intermediate pointers
 in c

 ast from 'uint8_t **' to 'const uint8_t **' must be 'const' qualified
 [-Wcast-qu

 al]

 C:\Users\jkolb\AppData\Local\Temp\ccxfMncr.s: Assembler messages:

 C:\Users\jkolb\AppData\Local\Temp\ccxfMncr.s:15685: Error: operand type
 mismatch

  for `cmp'

 make: *** [libswscale/swscale.o] Error 1



 Is there a way around this w/o disabling mmx/3dnow etc.?



Without looking at the code, I wouldn't be surprised if this is inline
assembly code that was written for 32 bit assembler.

--
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] c++ os specific and currently gcc-4_5-branch svn

[Doug Semler]

On Tue, Jun 22, 2010 at 3:24 AM, t66...@gmail.com t66...@gmail.com wrote:
 On 21/06/2010 10:43 PM, Doug Semler wrote:

 On Sun, Jun 20, 2010 at 11:38 PM, t66...@gmail.comt66...@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++
 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 libstdc++ ATM it defaults to using a strictly C99
 implementation of.

 So far I see it is breaking the cstdlib and cwchar.

 Until somebody fixes this C99 specific stuff of Cplusplus it is broken.


 Do you have an example, including preprocessed source, of the failure?


 http://sourceforge.net/tracker/index.php?func=detailaid=2990320group_id=202880atid=983356


Without the preprocessed source of the module that is giving the link
error as described in the tracker, I cannot determine the issue
because I am just guessing as to the problem, as I cannot reproduce
it.

The link error described should give the module that is attempting to
pull the unresolved symbol.  Run the same g++ command line that
compiles that source file into an object with the additional option
-save-temps in order to generate the ccfilename.ii file, and post
that.  Also, post the output of x86_64-w64-mingw32-gcc -v.

The reason we need that to assist is the following test program
compiles and links properly.

GNU C++ (GCC) version 4.5.1 20100620 (prerelease) [gcc-4_5-branch-drs
revision 161044] (x86_64-w64-mingw32)
compiled by GNU C version 4.5.1 20100620 (prerelease)
[gcc-4_5-branch-drs revision 161044], GMP version 5.0.1, MPFR version
3.0.0, MPC version 0.8.2

x86_64-w64-mingw32-g++ foo.cc

#include cstdlib

int funca() { exit(1); }
int funcb() { _exit(2); }
int funcc() { std::exit(3); }
int funcd() { std::_Exit(4); }
int funce() { ::_Exit(5); }

int main()
{
  return 0;
}

--
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] c++ os specific and currently gcc-4_5-branch svn

[Doug Semler]

On Sun, Jun 20, 2010 at 11:38 PM, t66...@gmail.com 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++
 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 libstdc++ ATM it defaults to using a strictly C99
 implementation of.

 So far I see it is breaking the cstdlib and cwchar.

 Until somebody fixes this C99 specific stuff of Cplusplus it is broken.


Do you have an example, including preprocessed source, of the failure?

--
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] #include ddk/ntddk.h fails without -I...include/ddk

[Doug Semler]

On Sun, Jun 20, 2010 at 12:03 PM, Henry N. henrynmail-mi...@yahoo.de wrote:
  Hello,

 in the 32 bit build environment a simple include like

   cat check.c 
     #include ddk/ntddk.h
  end check.c 

 works with that command line:

     i686-pc-mingw32-gcc -c check.c

 With the 64 bit toolchain (20100604_sezero) and headers from
 mingw-w64/experimental/ddk_test SVN 2511:

     x86_64-w64-mingw32-gcc -c check.c

 this fails with missing headers, for example:
 .../x86_64-w64-mingw32/include/ddk/ntddk.h:38:17: error: wdm.h: No such
 file or directory
 .../x86_64-w64-mingw32/include/ddk/ntddk.h:42:17: error: mce.h: No such
 file or directory

 I know, that I can set -I$PREFIX/x86_64-w64-mingw32/include/ddk. But,
 the $PREFIX is a problem in this case. This needs an absolute path. The
 toolchain I can install somewhere and simple set the variable PATH for
 the binaries is enough to work. But now, for the DDK headers I need to
 know the absolute PATH of toolchin in the project Makefile for the the
 include path. :-(

 Any ideas?

 Is using  #include ddk/ntddk.h a generally foul, and I needs to use
 #include ntddk.h?

 --

If I remember correctly, even the MS DDK suffers this problem.
However the reason that you don't see it is that the batch file that
is used to set up the build environment includes the install location
in the include path.

I really don't know the best way to handle it, because if you #include
ddk/ntddk.h I don't think you'll pick up the files properly when
building under msvc.

I'll have to think about this...

--
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

[Doug Semler]

Mercurial is a revision control system (like git, svn, etc).  In other
words it was fixed after the release and is in their public
repository.

You can safely ignore that particular test's error, the bug is in the
test-suite program itself.  If you want to see it be clean, you could
apply the patch that I posted and rerun the test.

On Thu, Jun 10, 2010 at 5:57 PM, Chris Saunders e...@mountaincable.net wrote:
 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] Problem with MSYS on 64-bit

[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

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

[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] link error when building openexr ilmbase library...

[Doug Semler]

On Tue, Jun 1, 2010 at 10:13 PM, Hradec hra...@hradec.com wrote:
 also, by doing a grep _eLut, this is the result:

 hradec$ grep '_eLut'
 /Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/./build/mingw/ilmbase-1.0.1/lib/*

 Binary file
 /Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/./build/mingw/ilmbase-1.0.1/lib/libHalf.a
 matches
 Binary file
 /Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/./build/mingw/ilmbase-1.0.1/lib/libHalf.so
 matches
 Binary file
 /Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/./build/mingw/ilmbase-1.0.1/lib/libHalf.so.6
 matches
 Binary file
 /Volumes/Data/Users/hradec/dev/svn/cortex4all/trunk/OIIO/externals/./build/mingw/ilmbase-1.0.1/lib/libHalf.so.6.0.0
 matches


 this is the lib folder from ilmbase:
 -rw-r--r--  1 hradec  admin   280K  1 Jun 03:44 libHalf.a
 -rwxr-xr-x  1 hradec  admin   986B  1 Jun 03:44 libHalf.la
 lrwxr-xr-x  1 hradec  admin    16B  1 Jun 03:44 libHalf.so -
 libHalf.so.6.0.0
 lrwxr-xr-x  1 hradec  admin    16B  1 Jun 03:44 libHalf.so.6 -
 libHalf.so.6.0.0
 -rwxr-xr-x  1 hradec  admin   352K  1 Jun 03:44 libHalf.so.6.0.0
 -rw-r--r--  1 hradec  admin   227K  1 Jun 03:44 libIex.a
 -rwxr-xr-x  1 hradec  admin   979B  1 Jun 03:44 libIex.la
 lrwxr-xr-x  1 hradec  admin    15B  1 Jun 03:44 libIex.so - libIex.so.6.0.0
 lrwxr-xr-x  1 hradec  admin    15B  1 Jun 03:44 libIex.so.6 -
 libIex.so.6.0.0
 -rwxr-xr-x  1 hradec  admin   249K  1 Jun 03:44 libIex.so.6.0.0
 -rw-r--r--  1 hradec  admin   142K  1 Jun 03:45 libIlmThread.a
 -rwxr-xr-x  1 hradec  admin   1.1K  1 Jun 03:45 libIlmThread.la
 lrwxr-xr-x  1 hradec  admin    21B  1 Jun 03:45 libIlmThread.so -
 libIlmThread.so.6.0.0
 lrwxr-xr-x  1 hradec  admin    21B  1 Jun 03:45 libIlmThread.so.6 -
 libIlmThread.so.6.0.0
 -rwxr-xr-x  1 hradec  admin   255K  1 Jun 03:45 libIlmThread.so.6.0.0
 -rw-r--r--  1 hradec  admin   164K  1 Jun 03:44 libImath.a
 -rwxr-xr-x  1 hradec  admin   1.1K  1 Jun 03:44 libImath.la
 lrwxr-xr-x  1 hradec  admin    17B  1 Jun 03:44 libImath.so -
 libImath.so.6.0.0
 lrwxr-xr-x  1 hradec  admin    17B  1 Jun 03:44 libImath.so.6 -
 libImath.so.6.0.0
 -rwxr-xr-x  1 hradec  admin   283K  1 Jun 03:44 libImath.so.6.0.0
 drwxr-xr-x  3 hradec  admin   102B  1 Jun 03:45 pkgconfig

 I got no bin folder and no dll's... only this lib and the include.



It's looking like the package built for the native system.  Either
that or you're trying to mix and match the target libraries in the
same directory (bad idea).  The .so files are not for the windows
target.  Maybe you misconfigured the library package - when cross
compiling you probably need to specify
--host=x86_64-w64-mingw32

not

--target=x86_64-w64-mingw32

The --target parameter is used only when creating a cross compiler
(telling the compiler what it's going to be targeting).   While
normally you'll specify --host, which tells the configuration routines
what the machine you will be RUNNING the result on.

--

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

Re: [Mingw-w64-public] Custom toolchain build with gcc-4.4.5 (2010-05-15)

[Doug Semler]

On Sun, May 16, 2010 at 4:52 PM, Wolfgang Glas wolfgang.g...@ev-i.at wrote:
 On 2010-05-16 22:43, Ozkan Sezer wrote:
 On Sun, May 16, 2010 at 11:03 PM, Wolfgang Glas wolfgang.g...@ev-i.at 
 wrote:

 [snip]

 For the next builds, I will include this, thanks.
 BTW, same effect can also be accomplished by
 adding a format string to the sprintf call, too.

 Yes, 'sprintf(dest,%s,src)' is equal to 'strcpy(dest,src)', if that makes 
 your
 code honestly more readable ;-)


Thanks, guys.  I'll change it, since that could expose security hole
if the dllname has a format specifier in it (which would be odd, but
possible since the only chars skipped for dll name are ':' '\' and
'/')...(I think this was a
copy-pasto-forgot-to-change-sprintf-to-strcpy).

BTW, from where is the compilation flag -Wformat-nonliteral coming,
since this is required to get this message from gcc...even -Wall
doesn't turn it on in 4.5 which is why this was missed ;-)

--

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

Re: [Mingw-w64-public] Custom toolchain build with gcc-4.4.5 (2010-05-15)

[Doug Semler]

Posted.  sprintf now strcpy for the calls...

--

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

Re: [Mingw-w64-public] Mingw + mkl

[Doug Semler]

2010/5/14 Tony Theodore to...@logyst.com:
 2010/5/15 Mario Rodríguez shi...@gmail.com:
 Hi,

 I want to use *MKL*`s lapack  BLAS in my *mingw* project.

 I use this libraries for 32 bits linking: mkl_intel_c_dll.lib,
 mkl_intel_thread_dll.lib, mkl_core_dll.lib. In 32b arquitecture, it´s
 enought adding this files names at the end of the g++ linking line.

 But in 64 bits (using mingw-w64 project), it show me undefined
 references in all blas/lapack calls. I use:

 -mkl_intel_lp64_dll.lib
 -mkl_intel_thread_dll.lib
 -mkl_core-dll.lib

 It is possible to do? Maybe using dlltool/reimp or some tool similar?

 Thanks in advance!

 Try the link advisor [1], selecting Linux to see the gcc options, to
 get some hints - and see the common errors [2] . Note also, you
 probably want ilp64 not lp64.

 Cheers,

 Tony

 [1] http://software.intel.com/en-us/articles/intel-mkl-link-line-advisor/
 [2] 
 http://software.intel.com/en-us/articles/intel-math-kernel-library-intel-mkl-for-linux-common-linking-errors/


No, the Mingw 64 target is  llp64, not ilp64...it's 32bit longs for
x64 targets. (sizeof(long) == 4, sizeof(long long) == 8, sizeof(void*)
== 8)...ilp64 is sizeof(long) == 8, which is wrong...

What is the exact error messages you are seeing?  I wouldn't be
surprised if you are running into the underscoring issue, and you may
need to upgrade to the latest compiler toolchains that has the leading
underscores removed for compatibility with the x64 ABI.

Doug

--

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

Re: [Mingw-w64-public] Linkage issues

[Doug Semler]

 In the build log, gcc command line is silenced.
 CC      libavformat/utils.o

 Is this a bug in the binutils or gcc-4.5 branch?

 You really should provide the actual compiler command.


If you want to see the actual compile command, either configure with
--disable-silent-rules

or

make V=1 ...

Because it looks like the configure/automake input was set to use
silent rules by default.

Also, are you out of disk space?  Do you have the dependencies
available at configure time (are they being found ... check
config.log)...


Those zero length files feel like you ran out of disk space to me...

--

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

Re: [Mingw-w64-public] Linkage issues

[Doug Semler]

On Sat, May 8, 2010 at 10:52 PM, t66...@gmail.com t66...@gmail.com wrote:
 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 changed the way ccache and gcc-4_5-branch or bin-cvs
 work.
 Because I have been using ccache for long time, used to worked well with
 gcc-4_4-branch + bin-cvs (dated 25-01-2010) with compiling all the
 libraries.
 Used ccache with gcc-4_5-branch + bin-cvs (dated 05-5-2010) to and compiled
 a lot of libraries ok, except ffmpeg.

 Because it looks like the configure/automake input was set to use
 silent rules by default.

 Also, are you out of disk space?

 No.
 bash-3.1$ df -H
 Filesystem             Size   Used  Avail Use% Mounted on
 /dev/root               37G    20G    15G  57% /

 The ccache, which came pre-compiled with the Linux O/S that I'm using.

 bash-3.1$ ccache -V
 ccache version 2.4
 Copyright Andrew Tridgell 2002
 Released under the GNU GPL v2 or later

 Removed ccache from the compile process, ffmpeg now build fine.
 I want to find out though, what is causing the problem.



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, after reading the website, there are
some fundamental things about it that i disagree with...but that's
just me

--

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

Re: [Mingw-w64-public] ld: skipping incompatible build/root/mingw/lib/libmingw32.a

[Doug Semler]

On Tue, Apr 27, 2010 at 1:37 AM, Mario Emmenlauer ma...@emmenlauer.de wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1


 Hi Doug,

 On 04/26/2010 03:37 PM, Doug Semler wrote:
 On Mon, Apr 26, 2010 at 6:25 AM, Mario Emmenlauer ma...@emmenlauer.de 
 wrote:
 On 04/25/2010 04:48 PM, Kai Tietz wrote:
 2010/4/25 Mario Emmenlauer ma...@emmenlauer.de:

 Hi all,

 I fail to build a canadian cross with mingw Revision: 2263 (current
 trunk).

 The error happens during make all-target-libgcc, message is:
  [cut]/build/root/x86_64-w64-mingw32/bin/ld: skipping incompatible \
  [cut]/build/root/mingw/lib/libmingw32.a when searching for -lmingw32

 There are more identical errors for other libs like kernel32 and
 msvcrt.


 objdump lists the correct format:
  [cut]/build/root/bin/x86_64-w64-mingw32-objdump --archive-headers \
  [cut]/build/root/x86_64-w64-mingw32/lib/libmingw32.a
    [...]
    lib64_libmingw32_a-tlsmcrt.o:     file format pe-x86-64

 Also, ld seems to be valid:
  [cut]/build/root/bin/x86_64-w64-mingw32-ld: supported targets: \
    pe-x86-64 pei-x86-64 elf64-x86-64 elf64-l1om elf64-little elf64-big
    elf32-little elf32-big srec symbolsrec verilog tekhex binary ihex


 Here is what I tried:
  - makefile: experimental/buildsystem/makebuildroot-test.mk
  - makefile: experimental/buildsystem/makebuildroot.mk
  - compile instructions from mingw64 sourceforge wiki

 Compiled with various combinations of
  - binutils-2.20.1, binutils-2.20.51 and binutils-trunk
  - gcc-4.4.3, gcc-4.5.0 and gcc-4.5.1-trunk

 Operating system:
  - Ubuntu 9.10 x86_64
  - Debian testing x86_64
  - Ubuntu 8.10 x86_64

 All result in the identical error message about 'skipping incompatible'
 when searching for mingw libs.

 Well, for me it is looking like that either your binutils version
 isn't a x64 defaulted one, or the libraries are build for 32-bit and
 not for 64-bit. Did you used for crt build '--enable-lib32' or
 '--enable-lib64'?

 Sorry that I forgot that crucial piece of information!

 I tried both with and without multilib, same result. Based on a
 suggestion from jon_y in IRC, I concentrate on without multilib first.
 For leaving out multilib, I do not add any of '--enable-lib32' or
 '--enable-lib64' to configure of mingw crt (but leave the default).
 For gcc and binutils, I do add '--disable-multilib' to configure.

 Is there an easy test whether any of the components targets the wrong
 architecture?

 I just checked from an i686 Ubuntu Hardy, same error. So its not related
 to the x86_64 architecture of the host OS.

 Can anybody successfully compile a canadian cross from Linux with
 current trunk? If yes, what are the specs and compile instructions
 used, so I have a reference?

 Cheers,


 Not with the current trunk but I've managed to get the 4.5 build going.

 I have a few patches that fix the gcc build system and also use
 version-specific-libraries.  Which means, unfortunately, my build
 scripts wouldn't work too well for you without the patches.

 If you want, I can send them but you'll have to apply some patches to
 make it work right for you :-/

 Great, thats very good news! Your setup would absolutely be an option
 for me! Since I don't require mingw in a production environment, I'm
 very flexible with the versions and everything. Also I don't require
 multilib, so I'm all flexible :-)

 Could you please send me the patches, and your specific version they
 apply to? I'll test them right away :-)

 Cheers,

   Mario

I am in the process of creating a mingw-w64 fork for gcc and binutils
at repo.or.cz...

Unfortunately the office has firewalls on ssh and git outgoing
ports...which means that I can't do anything till i get home (and I
was too tired last night to do anything).  When I get them up and
running I'll put the links up.  In addition, I'll add my build scripts
to the gcc project fork so that they can be looked at (when I clean
them up a bit :))

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

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

[Doug Semler]

On Tue, May 4, 2010 at 11:52 AM, t66...@gmail.com t66...@gmail.com wrote:
 On 4/05/2010 11:49 PM, Ozkan Sezer wrote:
 On Tue, May 4, 2010 at 4:46 PM, t66...@gmail.comt66...@gmail.com  wrote:

 On 4/05/2010 11:17 PM, Ozkan Sezer wrote:

 On Tue, May 4, 2010 at 4:00 PM, t66...@gmail.comt66...@gmail.com    
 wrote:


 You built a cross-binutils-2.20.1 but kept the rest as the same
 yes?

 Initially I built the gcc cross compiler with cross-binutils-cvs.

   I think that's why it fails. Binutils-cvs has the undrerscoring
 changes but release versions of gcc-4.4.4 and gcc-4.5.0 do
 not.

 So are you saying that I should use gcc-4.4.4 + binutils-cvs ?
 Or use gcc 4_4-branch + binutils-cvs?

 4.4 series will never officially have the underscoring
 changes unless you patch it yourself. Therefore, if you
 are using an unmodified 4.4.x, you should use binutils
 2.20.1 or a cvs snapshot= 2010-04-25.

 Thank you for the very helpful advice, I will try again later from the
 start.


Just a quick note:

You can use the binutils-cvs with gcc 4.4 series if you configure
binutils with --enable-leading-mingw64-underscores
You can build gcc 4.5 and 4.6 against older versions of binutils (or
binutils built with --enable-leading-mingw64-underscores) with the
same option during gcc's configure.

That option was purposely added for this reason :)

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

Re: [Mingw-w64-public] [Repost] LIBRARY_PATH environment variable not honoured.

[Doug Semler]

On Wed, Apr 21, 2010 at 6:05 AM, Sisyphus sisyph...@optusnet.com.au wrote:

 - Original Message - From: Doug Semler dougsem...@gmail.com
 To: Sisyphus sisyph...@optusnet.com.au
 Cc: mingw64 mingw-w64-public@lists.sourceforge.net
 Sent: Wednesday, April 21, 2010 2:45 AM
 Subject: Re: [Mingw-w64-public] [Repost] LIBRARY_PATH environment variable
 not honoured.


 Oops, should have qualified that - i meant the output during
 compileIOW make CFLAGS=-v

 If I run 'x86_64-w64-mingw32-gcc -c try.c -v' (where try.c is a simple
 hello script), will that give you all you need ? (Ouptut attached.) It
 occurred to me later at work (where I had no internet connection) that you
 were probably after that.

 If that's still not right, just yell at me and I'll do as you asked above
 :-)

 I see a LIBRARY_PATH specified in the output - that has nothing to do with
 my LIBRARY_PATH env var. (If I remove that environment variable, I still get
 the same result.)


Well, it looks like the compiler may be being built with host !=
target... In other words it wasn't bootstrapped and has been
configured as a cross compiler...

LIBRARY_PATH is ignored in cross compilers.

The buildbot that builds this should probably override the
configuration guess, by both passing the --host=x86_64-w64-mingw32 on
the configure line, and also by passing --enable-bootstrap if it's
being built on a 64 windows machine.  I don't know how well this would
work, but it could be tried

If host != target, CROSS_DIRECTORY_STRUCTURE is defined, which then
turns off several environment variables (that wouldn't be suitable for
a cross compiler)...

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

Re: [Mingw-w64-public] [Repost] LIBRARY_PATH environment variable not honoured.

[Doug Semler]

On Sun, 18 Apr 2010 10:52:26 Sisyphus wrote:
 Hi,
 
 I asked about this on 14 Oct last year
 (http://sourceforge.net/mailarchive/forum.php?thread_name=A00A469F7EBE44199
 92A92CBC29D03F5%40desktop2forum_name=mingw-w64-public) and didn't get any
 replies - so I thought I'd ask again and see what information I can glean
 this time.
 
 With mingw32 (from mingw.org), I have built and installed a number of
 libraries (eg gmp) in C:\_32\msys\1.0\local\lib.
 Because I have set the LIBRARY_PATH environment variable to
 'C:\_32\msys\1.0\local\lib', I can link to those libraries without having
 to use the -L switch. That is, I can build gmp apps by running:
 
 gcc -o gmp_app.exe gmp_app.c -lgmp
 
 With mingw64, the corresponding libs are in C:\_64\msys\1.0\local\lib and,
 again, I've set the LIBRARY_PATH environment variable to that directory.
 But the same command can't find the gmp library, and therefore fails.
 Instead, I have to run
 
 gcc -o gmp_app.exe gmp_app.c -LC:\_64\msys\1.0\local\lib -lgmp
 
 With mingw64, is there currently some way I can avoid having to use the -L
 switch in relation to libraries in that location ?
 If not, are there any plans to introduce such a feature ?
 

This is an environment/gcc thing, and not a mingw64 thing.  gcc searches the 
paths in a specific order (pass the -v command line option to see what it is).

I don't know how gcc reacts to LIBRARY_PATH.   I don't use it. IMHO, 
LIBRARY_PATH is a bad thing, as you can end up picking up the wrong things.   
I think it's always better to be able to see what's going on :)

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] [Mingw-users] Error message from assembler with mingw-w64-1.0-bin_i686-mingw_20100405

[Doug Semler]

2010/4/13 Doug Semler dougsem...@gmail.com:
 I have to run but I quickly looked at it and it looks like there may
 be an parentheses around %1 in InterlockedIncrement64 and
 InterlockedDecrement16 inline declarations in winnt.h which are being
 expanded to ((%rcx)) in the assembly (which is incorrect).


Yes, this is the issue.  The following code exposes it completely
(without the variation in command line parameters):

#include windows.h

int main()
{
LONG64 bar = 41;
LONG64 foo = InterlockedIncrement64(bar);
return (int) foo;
}

prompt gcc -c -m64 -O2 foo.c -save-temps
foo.s: Assembler messages:
foo.s:15: Error: missing ')'
foo.s:15: Error: junk `(%rsp))' after expression

Offending line of foo.s:

lock
xaddq %rax,(40(%rsp))
 # 0  2
/NO_APP
movl40(%rsp), %eax

Note the extra parenthesis around the dest register location of the
xaddq instruction.

The following patch fixes this for both InterlockedIncrement64 and
InterlockedDecrement16:

mingw-w64-headers/include/ChangeLog:
* winnt.h (inline InterlockedDecrement16, InterlockedIncrement64):
  Remove parentheses from destination regsiter

diff --git i/mingw-w64-headers/include/winnt.h
w/mingw-w64-headers/include/winnt.h
index 2c0be70..8a336bc 100644
--- i/mingw-w64-headers/include/winnt.h
+++ w/mingw-w64-headers/include/winnt.h
@@ -1259,7 +1259,7 @@ typedef DWORD LCID;
 __CRT_INLINE SHORT InterlockedDecrement16(SHORT volatile *Addend) {
   SHORT ret = -1;
   __asm__ __volatile__(lock\n\t
-  xaddw %0,(%1)
+  xaddw %0,%1
   : +r (ret), +m (*Addend)
   : : memory);
   return ret - 1;
@@ -1345,7 +1345,7 @@ typedef DWORD LCID;
 __CRT_INLINE LONG64 InterlockedIncrement64(LONG64 volatile *Addend) {
   LONG64 ret = 1LL;
   __asm__ __volatile__ (lock\n\t
-  xaddq %0,(%1)
+  xaddq %0,%1
   : +r (ret), +m (*Addend)
   : : memory);
   return ret + 1LL;

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] delay import support for mingw-w64

[Doug Semler]

On Apr 9, 2010, at 15:51, NightStrike nightstr...@gmail.com wrote:

 On Mon, Oct 26, 2009 at 10:35 AM, Kai Tietz  
 ktiet...@googlemail.com wrote:
 2009/10/26 NightStrike nightstr...@gmail.com:
 On Thu, Sep 10, 2009 at 3:40 AM, Kai Tietz  
 ktiet...@googlemail.com wrote:
 2009/9/10 GCC G++ cplusplu...@gmail.com:
 Since dlltool delay import has been add in the newest  
 binutils-2.20, will
 mingw-w64 people add w64 support to it in the near future?
 Thanks.

 For 32-bit mingw-w64 already supports delayed load library feature.
 For 64-bit some adjustments in dll tool are necessary (the assembly
 written there for x64 case isn't correct), but by changing this, it
 should work for x64 then, too.

 Is there a patch already for this?


 No, I have at the moment more important features to do. But it is on
 my pile for things to do.

 Just wanted to ping on this so it isn't forgotten.

I actually started to do some work in this area both in dlltool and  
the linker (linker support for the delay version of the .idata sections)

I'm still waiting for my FSF paperwork that's finally on its way but  
if someones already doing this I'll just delay my work (pun  
intended).  Especially if I ever get around to moving the import  
generation to bfd...


--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Sysroot Build-sysroot

[Doug Semler]

On Thu, 25 Mar 2010 08:36:19 Dmitrijs Ledkovs wrote:
 After spending a lot of time in Debian chroot's used for building
 package I thought that there must be an easier way of building
 circular dependencies.
 
 The cunning feature is to build --with-sysroot  --with-build-sysroot.
 Binutils  GCC support that.
 
 In my debian packages I currently build with --prefix=/usr
 --with-sysroot=/usr and now --with-build-sysroot=$(CURDIR)/sysroot
 
 This way I can build each package in turn (binutils, headers, all-gcc,
 crt, intall-gcc) with above configure options, and after each steps
 doing $make install DESTDIR=$(CURDIR)/sysroot.
 
 The benefit is that now you can do a local self-contained build with
 $build_sysroot without installing anything into the intended $sysroot
 for end-users.
 
 The need is for debian packaging ;-) I can now walk into the buildd
 jail with all sources and walk out with working cross-compiled
 ready-for-consumption binary packages.
 
 The hack is very crude and I understand that it might be rejected. Oh
 well, at least I've tried.

Hmm.  I actually extended the idea even further locally, which hacks up the 
gcc build process in such a way that in a combined tree (headers and crt 
separate).  It basically does the following:

   1) Builds and installs the headers into the build-sysroot prior to building 
gcc
   2) Builds and installs the crt into build-sysroot prior to configuring the 
target libgcc.
   3) During the install phase, it installs into the sysroot.

I am lazy though, and hacked up my tree pretty good so that things are 
installed into the places *I* believe they should be installed (and also 
removed some things *I* don't believe should be there), so that may be why it 
works well for me :)  

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] typo in new disable leading underscores

[Doug Semler]

Noticed a typo when configuring the leading underscores in the crt:

configuration output says:

configure:5078: checking whether to disable leading underscores
configure:5103: result: no

when the --disable-leading-underscores is passed (and result: yes when
not passed).  In other words, whether to disable should probably be
whether to enable since the result is the value of enable

 (confused me a bit when I was verifying something :))

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
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 building a static gsl-1.14

[Doug Semler]

On Wed, Mar 24, 2010 at 1:26 PM, JonY jo...@users.sourceforge.net wrote:
 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 turned out
 to be a libtool (ltmain.sh) bug. However, I've been unable to adapt the
 ltmain.sh patch that worked there to my particular situation.

 No problems with a dynamic build of gsl-1.14, btw ... it's just the static
 build that's being uncooperative.

 When trying to build a static gsl-1.14 library with mingw64 in the MSYS
 shell, I start with:

 $ ./configure --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
 CC=x86_64-w64-mingw32-gcc CXX=x86_64-w64-mingw32-g++
 AR=x86_64-w64-mingw32-ar
 LD=x86_64-w64-mingw32-ld NM=x86_64-w64-mingw32-nm
 RANLIB=x86_64-w64-mingw32-ranlib --disable-shared --enable-static  make

 (For the dynamic build I use the same, except that it's
 --disable-static --enable-shared.)
 Everything is fine until we get near the end of the make process, when this
 happens:

 ##
 /bin/sh ./libtool --tag=CC   --mode=link
 x86_64-w64-mingw32-gcc  -g -O2 -version-info 15:0:15 -no-undefined  -o
 libgsl.la -rpath /usr/local/lib version.lo block/libgslblock.la
 blas/libgslblas.la bspline/libgslbspline.la
 [SNIP lots of other.la files]
 wavelet/libgslwavelet.la cblas/libgslcblas.la -lm
 libtool: link: (cd .libs/libgsl.lax/libgslblock.a  x86_64-w64-mingw32-ar x
 /c/_64/comp/gsl-1.14/block/.libs/libgslblock.a)
 libtool: link: object name conflicts in archive:
 .libs/libgsl.lax/libgslblock.a//c/_64/comp/gsl-1.14/block/.libs/libgslblock.a
 make[2]: *** [libgsl.la] Error 1
 make[2]: Leaving directory `/c/_64/comp/gsl-1.14'
 make[1]: *** [all-recursive] Error 1
 make[1]: Leaving directory `/c/_64/comp/gsl-1.14'
 make: *** [all] Error 2
 ###

 The 'cd .libs/libgsl.lax/libgslblock.a  x86_64-w64-mingw32-ar x
 /c/_64/comp/gsl-1.14/block/.libs/libgslblock.a' command apparently
 succeeds - the 3
 object files in libgslblock.a are to be found in the
 .libs/libgsl.lax/libgslblock.a/ folder.

 Does that error mean anything to anyone here ?
 Any advice on something I could try to get around it ?

 My x86_64-w64-mingw32-gcc -v is provided below my sig.

 Cheers,
 Rob

 r...@desktop2 ~
 $ x86_64-w64-mingw32-gcc -v
 Using built-in specs.
 Target: x86_64-w64-mingw32
 Configured with:
 ../../../build/gcc/gcc/configure --target=x86_64-w64-mingw32 
 --prefix=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/root
   
 --with-sysroot=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/root 
 --with-gmp=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/gmp/install
  
 --with-mpfr=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/mpfr/install
  
 --with-mpc=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/mpc/install
  --enable-languages=all,obj-c++ --enable-fully-dynamic-string 
 --disable-multilibThread model: win32gcc version 4.4.4 20100208 
 (prerelease)(GCC)


 Hi,

 Strange, there should not be any folders below .libs.


Sure there should - he's building a static library.  This means that
libtool will extract all the archive members from the dependent
(convience/static) libraries and add them to the final library.

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
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 building a static gsl-1.14

[Doug Semler]

On Wed, Mar 24, 2010 at 2:24 PM, Doug Semler dougsem...@gmail.com wrote:
 On Wed, Mar 24, 2010 at 1:26 PM, JonY jo...@users.sourceforge.net wrote:
 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 turned out
 to be a libtool (ltmain.sh) bug. However, I've been unable to adapt the
 ltmain.sh patch that worked there to my particular situation.

 No problems with a dynamic build of gsl-1.14, btw ... it's just the static
 build that's being uncooperative.

 When trying to build a static gsl-1.14 library with mingw64 in the MSYS
 shell, I start with:

 $ ./configure --build=x86_64-w64-mingw32 --host=x86_64-w64-mingw32
 CC=x86_64-w64-mingw32-gcc CXX=x86_64-w64-mingw32-g++
 AR=x86_64-w64-mingw32-ar
 LD=x86_64-w64-mingw32-ld NM=x86_64-w64-mingw32-nm
 RANLIB=x86_64-w64-mingw32-ranlib --disable-shared --enable-static  make

 (For the dynamic build I use the same, except that it's
 --disable-static --enable-shared.)
 Everything is fine until we get near the end of the make process, when this
 happens:

 ##
 /bin/sh ./libtool --tag=CC   --mode=link
 x86_64-w64-mingw32-gcc  -g -O2 -version-info 15:0:15 -no-undefined  -o
 libgsl.la -rpath /usr/local/lib version.lo block/libgslblock.la
 blas/libgslblas.la bspline/libgslbspline.la
 [SNIP lots of other.la files]
 wavelet/libgslwavelet.la cblas/libgslcblas.la -lm
 libtool: link: (cd .libs/libgsl.lax/libgslblock.a  x86_64-w64-mingw32-ar x
 /c/_64/comp/gsl-1.14/block/.libs/libgslblock.a)
 libtool: link: object name conflicts in archive:
 .libs/libgsl.lax/libgslblock.a//c/_64/comp/gsl-1.14/block/.libs/libgslblock.a
 make[2]: *** [libgsl.la] Error 1
 make[2]: Leaving directory `/c/_64/comp/gsl-1.14'
 make[1]: *** [all-recursive] Error 1
 make[1]: Leaving directory `/c/_64/comp/gsl-1.14'
 make: *** [all] Error 2
 ###

 The 'cd .libs/libgsl.lax/libgslblock.a  x86_64-w64-mingw32-ar x
 /c/_64/comp/gsl-1.14/block/.libs/libgslblock.a' command apparently
 succeeds - the 3
 object files in libgslblock.a are to be found in the
 .libs/libgsl.lax/libgslblock.a/ folder.

 Does that error mean anything to anyone here ?
 Any advice on something I could try to get around it ?

 My x86_64-w64-mingw32-gcc -v is provided below my sig.

 Cheers,
 Rob

 r...@desktop2 ~
 $ x86_64-w64-mingw32-gcc -v
 Using built-in specs.
 Target: x86_64-w64-mingw32
 Configured with:
 ../../../build/gcc/gcc/configure --target=x86_64-w64-mingw32 
 --prefix=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/root
   
 --with-sysroot=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/root
  
 --with-gmp=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/gmp/install
  
 --with-mpfr=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/mpfr/install
  
 --with-mpc=/g/buildbot/vista64-mingw32/mingw-x86-x86_64/build/build/mpc/install
  --enable-languages=all,obj-c++ --enable-fully-dynamic-string 
 --disable-multilibThread model: win32gcc version 4.4.4 20100208 
 (prerelease)(GCC)


 Hi,

 Strange, there should not be any folders below .libs.


 Sure there should - he's building a static library.  This means that
 libtool will extract all the archive members from the dependent
 (convience/static) libraries and add them to the final library.


Actually, the command that's failing is:

  x86_64-w64-mingw32-ar t
/c/_64/comp/gsl-1.14/block/.libs/libgslblock.a | sort | sort -uc

(The error message is misleading because it prepends the extract
directory onto the archive name, and it is not the actual command
that's failing).

if you run that command, what happens?

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Include paths, float.h

[Doug Semler]

On Tue, Mar 23, 2010 at 9:02 AM, Ozkan Sezer seze...@gmail.com wrote:
 On Tue, Mar 23, 2010 at 3:00 PM, NightStrike nightstr...@gmail.com wrote:
 On Tue, Mar 23, 2010 at 8:48 AM, Ozkan Sezer seze...@gmail.com wrote:
 I can't understand, how can a fixinclude fix this thing??

 As I understand it, our headers are already being fixincluded. It's
 fixincludes that causes GCC to override us.  That means that there's
 stuff in our headers that GCC doesn't like.


 No, absolutely not. Can't you see what is already
 in your own fixinclude directory in your installation?
 The problem is with the headers installed by gcc
 by default.


I'll have to look, but it seems to me that that for it to work, the
system headers must be available during the all-gcc step of a
cross-compiler, wouldn't they, because fixincludes I believe is run
right after the compiler is built during that step...

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] (ups prior wrong list): Patch for binutils to support --(no-)leading-underscore in ld for x64/x86

[Doug Semler]

On Mon, Mar 22, 2010 at 12:08 PM, Doug Semler dougsem...@gmail.com wrote:
 On Mon, Mar 22, 2010 at 11:32 AM, Kai Tietz ktiet...@googlemail.com wrote:
 Hello,

 I prepared a patch which supports underscoring option for ld for
 x64/x86 pe-coff targets. I post it first here, so that possibly Doug
 could comment on it.

 I have to add for it some additional test-cases in testsuite before
 posting it upstream.


 I'll look at it more closely after lunch in comparison to what I did
 (actually dig out my notes) but right now after a quick glance it
 seems to me that I also had to play with pe_details_type-underscored
 on the x86_64 target in ld/pe-dll.c to generate exports and imports
 correctly...  But that may be because i also turned off underscoring
 by default when building in bfd/config.bfd, bfd/pe-x86_64.c and
 bfd/pei-x86_64.c (i.e. targ_underscore=no in config.bfd, and #define
 TARGET_UNDERSCORE 0 in the .c files) using a configure option.

Never mind...I looked at it more carefully after I ate and see that it
was done (I only saw the changes in the .em files when I first looked)
:)

Anyway a couple things:
  Maybe include a configure option to default the toolchain
(--disable-leading-underscores in bfd/configure - be consistent :))?
This could modify the config.bfd and pe[i]-x86_64.c to correctly
default TARGET_UNDERSCORE.  The mingw portion really doesn't need it
since it is built by dlltool compiled .o files directly (and not
linked, which is where this is really needed), but it would be nice to
have :)

Caveats that I see (not really on the binutils side but still there
nonetheless):
 1) When using a default no underscore toolchain, GCC must have
CFLAGS_FOR_TARGET=-fno-leading-underscore on the x64 build of the
target libraries during its build (i.e. make all-target-lib*), so that
it generates the correct code.  Or it needs to be defaulted to no
underscore.  When I first looked at this, I thought I could define
USER_LABEL_PREFIX to check at runtime (instead of _ or , define it
to something like ((TARGET_64BIT)  ix86_abi==MSABI) ?  : _).
But it turns out that collect2 uses this define as well and needs it
to not access those arch specific areas.  So defining
USER_LABEL_PREFIX that way really doesn't work in a multilib build
without some hacking of the defines if the leading underscores are
different for the two arch's.  If it's not a multilib build, then it's
easy since you can switch on !defined (TARGET_BI_ARCH) and use
TARGET_64BIT_DEFAULT to figure out what arch you are using.  The hack
to collect2 to get the correct behavior is ugly, by the way :)

2) If you don't configure binutils to default to no underscore in the
target vector, GCC also needs to pass --no-leading-underscores to the
linker, either via -Wl,--no-leading-underscores passed (e.g. again in
CFLAGS_FOR_TARGET) or by having its linker spec modified so that it is
passed during the link phase if -fno-leading-underscore is passed.
Not sure whether that second one is really a good idea, but we are
talking about this specific toolchain.

3) The link spec needs to be modified anyway if no-leading-underscore
is being used, because right now gcc passes the explicit
_dllmaincrtstar...@12 during a DLL link, which doesn't exist in the
non-underscored mingw startups (built with configure
--disable-leading-underscores)...so you need something like (say for a
defaulted no leading underscore toolchain - done this way so that you
could potentially configure GCC differently depending on whether
binutils is defaulted to no underscore)

   %{shared: %{mdll: %eshared and mdll are not compatible}} \
   %{shared: --shared} %{mdll:--dll} \
   %{static:-Bstatic} %{!static:-Bdynamic} \
-  %{shared|mdll: -e _dllmaincrtstar...@12 --enable-auto-image-base} \
+   ENTRY_LINK_SPEC  \
   %(shared_libgcc_undefs)

+#define ENTRY_LINK_SPEC %{shared|mdll: --enable-auto-image-base \
+  %{ SPEC_64 :-e DllMainCRTStartup} \
+  %{ SPEC_32 :-e _dllmaincrtstar...@12}}

Regardless of the changes made to GCC, if you don't default the target
in binutils to use it, anything that tries to use a no-underscored
mingw32 will need to remember to run gcc -fno-leading-underscore and
also somehow have the -Wl,--no-leading-underscore link option, which
is really why I like the idea of being able to completely default the
entire toolchain one way or the other (i.e. the same configure flag
that can turn it on and off in binutils, mingw, and gcc).  Of course,
defaulting the toolchain to no leading underscores means rebuilding
and requiring the correct toolchain all the way across the board,
since it would be pretty much be breaking the ABI...

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev

Re: [Mingw-w64-public] Question about the undercore in svn

[Doug Semler]

On Sun, Mar 21, 2010 at 8:31 PM, NightStrike nightstr...@gmail.com wrote:
 On Sun, Mar 21, 2010 at 7:24 PM, Doug Semler dougsem...@gmail.com wrote:
 On Sun, 21 Mar 2010 18:37:12 NightStrike wrote:
 On Sun, Mar 21, 2010 at 2:10 PM, Doug Semler dougsem...@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 into the
  completely wrong spot due to a -bindir parameter in the libtool portion
  of the DLL makefiles. They are installed into the host's binary
  directory (which makes no sense to me at all - by the way I use a
  different -prefix and -exec-prefix), they cannot be overridden by the
  --with-slibdir (unlike the libgcc-sjlj-1.dll, which can be overridden
  and which I have working multilib with a minor patch to
  gcc/config/t-cygming), nor do they obey the version specific runtime
  libs directory like the native toolchain does.  In addition, the
  mulitlib install can clobber the dlls in that (wrong) bindir with the
  wrong arch type (the 32bit install puts the 64 bit version there after
  all is said and done).

 Jon Y has a patch for all of that.

  Given that  the trunk of GCC is in stage 4, I wouldn't expect any of this
  to be fixed prior to the release even if patches were submitted since I
  wouldn't expect this to be classified as a P1 issue (I don't think the
  w64-mingw32 toolchain is considered to be a primary target, is it?)

 Yeah, it's not getting fixed in 4.5.  And no, we aren't even a
 secondary target :(

  My frustration right now is that the GCC trunk has been in stage 4 since
  December...aside from the fact that I would be wary personally of moving
  to a stage 1 or 2 trunk of 4.6 just to get a working mulitilib gcc for
  these targets...
 
  After saying all that, the documentation about multilib should maybe have
  some caveats...

 Well, to be fair, we never advertised that it even exists... so.

 In both how-to-build docs, yes, you do :)

 Oh... well, hmm  We should probably change that.  In my defense,
 I've been away for a while :)

 I know that there was the the tools now track gcc statement and no more
 need to patch gcc.   One of the problems really is going to be requiring the
 use of the 4.6 trunk to get the correct behavior for installation of the
 toolchain (multilib notwithstanding, I still feel the installation of the
 target DLLs is also woefully incorrect, so I presume the patch mentioned 
 above
 does that as well) unless there are also plans to backport them to 4.5, which
 I would doubt.   I would never use the stage 1,2, or 3 trunks to build
 production code (well, maybe the stage 3 depending on the issues in it)-- 
 they
 are just too unstable --which means I'll track the 4.5 branch for quite a
 while.

 There's a few choices.  Foremost, I would bribe Kai into getting this
 committed to 4.6 the moment it opens up into stage 1.  That way, you
 are essentially using 4.5+patches, as opposed to somewhere in the
 middle of stage 1 4.6, which will have a lot more churn in the code.
 The best way to do that would be to have the binutils side already
 done.

 Beyond that...  just grin and bear it?  I dunno.. I'm open to
 suggestions.  How do you want us to support you?


Oh, I don't need you to support me in particular...I'm a pretty smart
guy :)  ...  I just don't like reinventing the wheel is all :)

In fact I'd be willing to volunteer to help with issues like this (in
what little free time I have that is) - at the least on discussing
things and at the most suggesting ideas or submitting patches for
discussion.  I'm still waiting for FSF paperwork myself so that I can
do things on the binutils side, and I'll probably do FSF paperwork on
the gcc side as well so that anything I run into can be at least
submitted for comment without problem.. The biggest thing right now is
that there are three projects that are interlinked...a change in
behavior in one may require a change in all three of binutils, gcc,
and the runtime...and really, where do you discuss those changes, all
three lists?   Even something as seemingly small as the underscore
stuff for x64 is something that cascades really quickly...

For example, the underscore stuff:
the binutils ld right now doesn't support turning it off without a
patch, which means that import and export objects can't be built
during link without the option (you get a bunch of 'cannot export'
stuff)
Even with the patch, gcc has the -fno-leading-underscore option, but
if you build mingw x64 with the no leading underscores, you have to
remember to build everything (from target libraries to your own code)
from that point forward with that option, or you need to patch gcc to
default to no leading underscore on 64 bit, which has its own set of
problems.
but that leads to: gcc will still not link 64 bit dlls correctly
without being patched, because the entry point will no longer be
correct in the spec file.  In addition, there's still

Re: [Mingw-w64-public] Question about the undercore in svn

[Doug Semler]

On Mon, Mar 22, 2010 at 3:39 PM, Kai Tietz ktiet...@googlemail.com wrote:
 2010/3/22 Doug Semler dougsem...@gmail.com:
 On Sun, Mar 21, 2010 at 8:31 PM, NightStrike nightstr...@gmail.com wrote:
 On Sun, Mar 21, 2010 at 7:24 PM, Doug Semler dougsem...@gmail.com wrote:


 Well, in fact is this entry-point a no issue. By a recent patch, ld is
 able to select the proper entry-point without the need of specifying
 the -e entry. So this argument is in fact deprecated. Major pain
 here is the backward-compatibility necessary for older binutils. Buf
 for 4.6 I would prefer to make a crued break in support of older
 binutils versions (at least if configure for using no-underscore
 variant).


In light of that - the patch for ld --no-leading-underscores doesn't
work if you don't patch gcc to handle that...because the linker will
select default entry of 1000 because it isn't able to find
_dllmaincrtstar...@12 that is passed by gcc as the desired entry
point.   I guess the logic for the entry point in the linker could be
looked at though...

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

[Mingw-w64-public] Question about the undercore in svn

[Doug Semler]

Quick question:

Are you sure you want to disable the leading underscore on the 32bit side with 
the --disable-leading-underscore and multilib?  Looking at it (without testing 
it, that is), it doesn't seem to me that it is appropriate...

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Small bug in building 64 bit libraries from 32 bit toolchain

[Doug Semler]

 Do you mean that your toolchain is multilib with 32-bit as the
 primary?  Otherwise, I don't see how a 32-bit chain builds a 64-bit
 lib.


Yes, of course...

binutils compiled with --target=i686-w64-mingw32
--enable-targets=i686-w64-mingw32,x86_64-w64-mingw32

gcc configured appropriately for mulitlib

Can't really see why it wouldn't work, except for the assembler flags missing :)

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] __int64 issue of compatibility with MSVC

[Doug Semler]

On Thu, 04 Mar 2010 17:20:07 Jim Michaels wrote:
 in MSVC,
 __int64 x=12345678901234567i64;
 
 point 1: this type __int64 doesn't require me to #include windows to
 define it.  in mingw and mingw-w64, one must #include basetsd.h. why?
 
 point 2: there are also __int32 __int16 and __int8 types.

If I remember correctly, anything that starts with two underscores is 
implementation defined, which means that __int64 is MS compiler specific, so 
including a separate header would make sense to pick it up in mingw 

Since this is a compiler specific (not really mingw but gcc), it makes sense to 
me, in fact IIRC, MSDN specifically states Microsoft Visual C Specific for 
those types.  If you need to be able to compile under multiple compilers, I 
would say grab a MS version of stdint.h (since MSVC doesn't have that) and 
#include that, and use the types from there (such as int64_t, int32_t, etc).  
If you just need a type that is at least 64 bits I believe MSVC from 6.0 on 
supports long long and unsigned long long (at least 64 but could be 
longer)

 
 point 3: mingw does not utilize the i64 constant thingy (whatever it's
 called) that tells the compiler that this number is of __int64 type.  I do
 not know if there is an i32 or i16 or i8 definition.

That's another GCC, not mingw thing.  GCC supports the suffix of LL and ULL for 
64 bit wide numbers.  MSVC from at least visual studio 2003 (maybe, but don't 
quote me, VC6) also supports these...

 
 
 BTW, 128-bit number type is in the C9X standard.  the new integral data
 types in C++ will be something like int64, int32, int128, int16, int8.
 
 http://www.open-std.org/JTC1/sc22/wg14/www/docs/n615.htm
 

C9X support in MSVC is flaky at best and nonexistent in several spots (see: 
stdint.h).  I mean the standard has been ratified since what, 2004?  even VS 
2008 doesn't have it!)

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] __int64 issue of compatibility with MSVC

[Doug Semler]

On Sun, 07 Mar 2010 14:59:50 Kai Tietz wrote:
 2010/3/7 Doug Semler dougsem...@gmail.com:
  On Thu, 04 Mar 2010 17:20:07 Jim Michaels wrote:
  in MSVC,
  __int64 x=12345678901234567i64;
  
  point 1: this type __int64 doesn't require me to #include windows to
  define it.  in mingw and mingw-w64, one must #include basetsd.h. why?
  
  point 2: there are also __int32 __int16 and __int8 types.
  
  If I remember correctly, anything that starts with two underscores is
  implementation defined, which means that __int64 is MS compiler specific,
  so including a separate header would make sense to pick it up in mingw
  
  Since this is a compiler specific (not really mingw but gcc), it makes
  sense to me, in fact IIRC, MSDN specifically states Microsoft Visual C
  Specific for those types.  If you need to be able to compile under
  multiple compilers, I would say grab a MS version of stdint.h (since
  MSVC doesn't have that) and #include that, and use the types from there
  (such as int64_t, int32_t, etc). If you just need a type that is at
  least 64 bits I believe MSVC from 6.0 on supports long long and
  unsigned long long (at least 64 but could be longer)
 
 Right, keywords/symbols with two leading underscores are extensions.
 The support of '__int8, __int16, __int32, __int64, and __int128' are
 builtin types. As the are combinable by 'signed/unsigned' they can be
 handled by typedefs. So we use for them at the moment defines in our
 headers, but of course this is just a work-a-round. The type __int128
 will be added to gcc's version 4.6 (a patch for it is already posted
 but needs review). I would like to have those other extension types
 supported by VC, too, but well, as those types aren't part of any
 C-specification, it is a bit hard to put them into gcc.
 
 The digit post-fixes 'i32,i64,i128, etc' are alse MS specific
 extensions (AFAIR long long type was introduced by MS beginning from
 VC 2005). It would be possible to add these to gcc (in fact it is
 mainly preprocessor feature), but again here is again the question, if
 this fits into any specific standards gcc wants to support.
 

You're probably right - I can't keep track of them all :)  In addition I think 
that the 64 bit long long may not be available unless compiling the code as 
C++ under 2005.   Personally I think MS should fix their compiler to be more 
compliant to C9X (inttypes.h comes to mind) than adding MS extensions to 
GCC...

The main question I have is to the original poster: if you are compiling under 
gcc/mingw, why the concern about MS specific extensions; since you would no 
longer be using them unless you need to be able to continue to compile under 
the MS compiler as well?  I mean, if you have to change the code anyway (to 
include the mingw specific headers to grab these definitions), why not change 
the code to be portable anyway?

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] i686-w64-mingw32 and x86_64-w 64-mingw32 coexisting

[Doug Semler]

On Sun, 21 Feb 2010 09:56:46 JonY wrote:
 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, but things like libiberty.a are in the
  'lib' directory of both compilers and they both have a 'mingw32'
  directory that is either a symlink or a copy of the corresponding
  compiler directory.
  
  Is libiberty used as a host lib or a target lib?
 
 Hi,
 
 libiberty is usually built by the host compiler, used by the newly
 built gcc backends. Some binutils tools use it too.
 
 IMHO, there is little reason to install it, sourceware make install
 does it anyway.

I think this library is really only necessary if you install bfd (from 
binutils), since libbfd and libopcodes depend on libiberty.  Otherwise, it's 
another compiler support library in the vein of zlib that is distributed in 
gcc. 

I don't install libbfd when installing the toolchain, so I have actually 
marked it (correctly or incorrectly) as no_install in the toplevel Makefile.def 
(I don't think I've never been able to make the --enable-libiberty-install=no 
work properly)

Personally, I think that libbfd is so unstable and poorly documented that I 
really don't know why it would be installed (with its dependencies) to link 
against - anything that dares to use it really should be source compiled 
against a specific version :)

(Although the toplevel Makefile.def file depends the libstdc++, libobjc, and 
fastjar on libiberty, I believe that this dependency is for target tools, and 
not the target libraries themselves, which would mean that the target library 
shouldn't be installed either...)

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public

Re: [Mingw-w64-public] Object file install type

[Doug Semler]

On Sat, Feb 20, 2010 at 9:53 AM, NightStrike nightstr...@gmail.com wrote:
 I changed that at one point.  I forget why :(

 I'll look into it and change it back if that makes the most sense.

 On Sat, Feb 20, 2010 at 8:46 AM, Doug Semler dougsem...@gmail.com wrote:
 I notice that the crt .o and .a files are installed as scripts rather
 than data, which causes their file mode to be installed as executable
 (in a cross compile environment)

 Is there a specific reason for this?  It seems to me that files such
 as crt32_SCRIPTS, lib32_SCRIPTS, etc should actually be crt32_DATA,
 lib32_DATA, etc, as these are not SCRIPTS (targets that are
 executable), but built DATA (static linker input files)

 Or am I missing something (as in behavior in an msys/cygwin/win32 type
 environment)?


Well an FYI I have it locally patched and it (seems :)) to work
properly on a cross-compiler build install.  Not saying that it would
work in a win32 environment though.

To me, it's really an annoyance more than anything else, but maybe
it's because I'm more pedantic (read anal) about things like that :)

--
Download Intel#174; Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public