HI
I am building the GEOS library with MinGW on win7, in the last step wjen
linking the library i get the following error.
libtool: link: g++ -shared -nostdlib
c:/Tools/MinGW/bin/../lib/gcc/i686-w64-mingw32/4.9.1/../../../../i686-w64-mingw32/lib/../lib/dllcrt2.o
What i have figured out so far is to list the default search path for gcc
in MinGW is to issue the command
gcc -### -o foo foo.c
This will produce the following:
$ gcc -### -o foo foo.c /c/dev/gcc.txt
gcc.exe: error: foo.c: No such file or directory
Using built-in specs.
Hey guys,
Can I get some clarification in lfind on x64 not using size_t* but using
unsinged int*
What is the best course of action to take ?
Is there anything that can be done in mingw-w64
Many Thanks
Martell
-- Forwarded message --
From: Rémi Denis-Courmont r...@remlab.net
Issue here is that referenced object 'unsigned int' has different size
to 'size_t' on Windows. Means that function might set only lower
32-bit to something meaningful, and so passing a size_t pointer to it
could lead to corrupted value in it.
Kai
Yes I agree with this.
Especially because lfind is dynamically linked to msvcrt
We didn't into this before on irc but
could we add something similar to this in header in mingw64
#define _lfind(a,b,c,d,e) _lfind(a,b,(unsigned int*)c,d,e)
Which explicitly casts it to (unsigned int *)
Would this
No, it wouldn't help, as we still have an strict-aliasing issue. And
additionally the upper 32-bit of object are containing random values
Kai
2014-11-04 17:36 GMT+01:00 Martell Malone martellmal...@gmail.com:
Yes I agree with this.
Especially because lfind is dynamically linked to msvcrt
We
---
mingw-w64-headers/include/opmapi.h | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
diff --git a/mingw-w64-headers/include/opmapi.h b/mingw-w64-headers/include/opmapi.h
index 085896f..4addf11 100644
--- a/mingw-w64-headers/include/opmapi.h
+++
The definition of the function appears to
define num is the number of elements in the table
If I am reading this correctly the value of size_t has to be set before
calling lfind
In this case the upper32 bits are already set to 0.
Except in the case where size_t is more than 0x elements
Thanks, patch is ok.
Kai
2014-11-04 17:57 GMT+01:00 Jacek Caban ja...@codeweavers.com:
---
mingw-w64-headers/include/opmapi.h | 13 +++--
1 file changed, 3 insertions(+), 10 deletions(-)
--
On 11/4/2014 21:05, Theuns Heydenrych wrote:
What i have figured out so far is to list the default search path for gcc
in MinGW is to issue the command
So there right at the end is the offending path, some script that should
extract the -L paths, is bringing the ' character in, at the end of
HI, thanks for the reply
I downloaded from here
http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win32/Personal%20Builds/mingw-builds/4.9.1/threads-posix/dwarf/i686-4.9.1-release-posix-dwarf-rt_v3-rev0.7z/download
On Wed, Nov 5, 2014 at 12:07 AM, JonY
11 matches
Mail list logo
