[Mingw-w64-public] unexpected EOF while looking for matching `
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 c:/Tools/MinGW/bin/../lib/gcc/i686-w64-mingw32/4.9.1/crtbegin.o .libs/inlines.o -Wl,--whole-archive algorithm/.libs/libalgorithm.a geom/.libs/libgeom.a geomgraph/.libs/libgeomgraph.a index/.libs/libindex.a io/.libs/libio.a linearref/.libs/liblinearref.a noding/.libs/libnoding.a operation/.libs/liboperation.a planargraph/.libs/libplanargraph.a precision/.libs/libprecision.a simplify/.libs/libsimplify.a triangulate/.libs/libtriangulate.a util/.libs/libutil.a -Wl,--no-whole-archive -L/c/mingw491/i686-491-posix-dwarf-rt_v3-rev0/mingw32/opt/lib -L/c/mingw491/prerequisites/i686-zlib-static/lib -L/c/mingw491/prerequisites/i686-w64-mingw32-static/lib' -Lc:/Tools/MinGW/bin/../lib/gcc/i686-w64-mingw32/4.9.1 -Lc:/Tools/MinGW/bin/../lib/gcc -Lc:/Tools/MinGW/bin/../lib/gcc/i686-w64-mingw32/4.9.1/../../../../i686-w64-mingw32/lib/../lib -Lc:/Tools/MinGW/bin/../lib/gcc/i686-w64-mingw32/4.9.1/../../../../lib -Lc:/Tools/MinGW/bin/../lib/gcc/i686-w64-mingw32/4.9.1/../../../../i686-w64-mingw32/lib -Lc:/Tools/MinGW/bin/../lib/gcc/i686-w64-mingw32/4.9.1/../../.. -lstdc++ -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt -lpthread -ladvapi32 -lshell32 -luser32 -lkernel32 -liconv -lmingw32 -lgcc_s -lgcc -lmoldname -lmingwex -lmsvcrt c:/Tools/MinGW/bin/../lib/gcc/i686-w64-mingw32/4.9.1/crtend.o-o .libs/libgeos-3-4-2.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libgeos.dll.a ../libtool: eval: line 7867: unexpected EOF while looking for matching `'' ../libtool: eval: line 7868: syntax error: unexpected end of file make[3]: *** [libgeos.la] Error 1 make[3]: Leaving directory `/c/cpp/dev/LibsExternal_/Gis/geos/geos-3.4.2/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/c/cpp/dev/LibsExternal_/Gis/geos/geos-3.4.2/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/c/cpp/dev/LibsExternal_/Gis/geos/geos-3.4.2' make: *** [all] Error 2 The problem is the ' after the -L/c/mingw491/prerequisites/i686-w64-mingw32-static/lib' , library path. I can go and fix it manually every time, but how can the makefile be fixed, so that this ' is not appended to the end of this path? Could it be that there is somewhere in mingw settings i can check for internal library paths? Regards -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] unexpected EOF while looking for matching `
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. COLLECT_GCC=c:\Tools\MinGW\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/Tools/MinGW/bin/../libexec/gcc/i686-w64-mingw32/4.9.1/lto-wrapper.exe Target: i686-w64-mingw32 Configured with: ../../../src/gcc-4.9.1/configure --host=i686-w64-mingw32 --build=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=/mingw32 --with-sysroot=/c/mingw491/i686-491-posix-dwarf-rt_v3-rev0/mingw32 --with-gxx-include-dir=/mingw32/i686-w64-mingw32/include/c++ --enable-shared --enable-static --disable-multilib --enable-languages=ada,c,c++,fortran,objc,obj-c++,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --disable-sjlj-exceptions --with-dwarf2 --disable-isl-version-check --disable-cloog-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=i686 --with-tune=generic --with-libiconv --with-system-zlib --with-gmp=/c/mingw491/prerequisites/i686-w64-mingw32-static --with-mpfr=/c/mingw491/prerequisites/i686-w64-mingw32-static --with-mpc=/c/mingw491/prerequisites/i686-w64-mingw32-static --with-isl=/c/mingw491/prerequisites/i686-w64-mingw32-static --with-cloog=/c/mingw491/prerequisites/i686-w64-mingw32-static --enable-cloog-backend=isl --with-pkgversion='i686-posix-dwarf-rev0, Built by MinGW-W64 project' --with-bugurl= http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -I/c/mingw491/i686-491-posix-dwarf-rt_v3-rev0/mingw32/opt/include -I/c/mingw491/prerequisites/i686-zlib-static/include -I/c/mingw491/prerequisites/i686-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/c/mingw491/i686-491-posix-dwarf-rt_v3-rev0/mingw32/opt/include -I/c/mingw491/prerequisites/i686-zlib-static/include -I/c/mingw491/prerequisites/i686-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe -L/c/mingw491/i686-491-posix-dwarf-rt_v3-rev0/mingw32/opt/lib -L/c/mingw491/prerequisites/i686-zlib-static/lib -L/c/mingw491/prerequisites/i686-w64-mingw32-static/lib' Thread model: posix gcc version 4.9.1 (i686-posix-dwarf-rev0, Built by MinGW-W64 project) 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 the line. No where that script is and how to fix it i dont know. Any suggestions? -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Fwd: [vlc-devel] [PATCH] fix lfind errors on windows
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 Date: Tue, Nov 4, 2014 at 1:25 PM Subject: Re: [vlc-devel] [PATCH] fix lfind errors on windows To: Mailing list for VLC media player developers vlc-de...@videolan.org Le 2014-11-04 15:03, Martell Malone a écrit : The issue here is there is nothing wrong with mingw-w64 as they link to msvcrt As defined here http://msdn.microsoft.com/en-us/library/a6xkkxfz.aspx [3] On little endian we can just ignore the warning but depending in the strictness of the build / package system this is not an option. I can conceive four cases: 1) lfind() is inline, 2) lfind() is statically linked and LTO is active, 3) lfind() is statically linked but LTO is inactive, 4) lfidn() is dynamically linked. The pointer aliasing violation is only a potential problem in cases 1 and 2. But binary compatibility with the CRT is only a concern in case 4. And even then, a small wrapper that converts back-and-forth would not be hard. So I fail to see an excuse. I'm totally not merging that ugly ifdef hack. -- Rémi Denis-Courmont ___ vlc-devel mailing list To unsubscribe or modify your subscription options: https://mailman.videolan.org/listinfo/vlc-devel -- ___ 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: [vlc-devel] [PATCH] fix lfind errors on windows
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 -- ___ 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: [vlc-devel] [PATCH] fix lfind errors on windows
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 solve anything ? Many Thanks Martell On Tue, Nov 4, 2014 at 4:17 PM, Kai Tietz ktiet...@googlemail.com wrote: 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 -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- ___ 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: [vlc-devel] [PATCH] fix lfind errors on windows
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 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 solve anything ? Many Thanks Martell On Tue, Nov 4, 2014 at 4:17 PM, Kai Tietz ktiet...@googlemail.com wrote: 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 -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] opmapi.h fixes.
---
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
+++ b/mingw-w64-headers/include/opmapi.h
@@ -8,8 +8,6 @@
#include dxva2api.h
-#if (_WIN32_WINNT = 0x0600)
-
#define OPM_OMAC_SIZE16
#define OPM_CONFIGURE_SETTING_DATA_SIZE 4056
#define OPM_REQUESTED_INFORMATION_SIZE 4076
@@ -225,11 +223,11 @@ DECLARE_INTERFACE_(IOPMVideoOutput,IUnknown)
STDMETHOD_(ULONG, Release)(THIS) PURE;
/* IOPMVideoOutput methods */
-STDMETHOD_(HRESULT,Configure)(THIS_ const OPM_CONFIGURE_PARAMETERS *pParameters,ULONG ulAdditionalParametersSize,const BYTE *pbAdditionalParameters) PURE;
-STDMETHOD_(HRESULT,COPPCompatibleGetInformation)(THIS_ const OPM_COPP_COMPATIBLE_GET_INFO_PARAMETERS *pParameters,OPM_REQUESTED_INFORMATION *pRequestedInformation) PURE;
+STDMETHOD_(HRESULT,StartInitialization)(THIS_ OPM_RANDOM_NUMBER *prnRandomNumber,BYTE **ppbCertificate,ULONG *pulCertificateLength) PURE;
STDMETHOD_(HRESULT,FinishInitialization)(THIS_ const OPM_ENCRYPTED_INITIALIZATION_PARAMETERS *pParameters) PURE;
STDMETHOD_(HRESULT,GetInformation)(THIS_ const OPM_GET_INFO_PARAMETERS *pParameters,OPM_REQUESTED_INFORMATION *pRequestedInformation) PURE;
-STDMETHOD_(HRESULT,StartInitialization)(THIS_ OPM_RANDOM_NUMBER *prnRandomNumber,BYTE **ppbCertificate,ULONG *pulCertificateLength) PURE;
+STDMETHOD_(HRESULT,COPPCompatibleGetInformation)(THIS_ const OPM_COPP_COMPATIBLE_GET_INFO_PARAMETERS *pParameters,OPM_REQUESTED_INFORMATION *pRequestedInformation) PURE;
+STDMETHOD_(HRESULT,Configure)(THIS_ const OPM_CONFIGURE_PARAMETERS *pParameters,ULONG ulAdditionalParametersSize,const BYTE *pbAdditionalParameters) PURE;
END_INTERFACE
};
@@ -262,7 +260,6 @@ HRESULT WINAPI OPMGetVideoOutputsFromIDirect3DDevice9Object(
IOPMVideoOutput ***pppOPMVideoOutputArray
);
-#if (_WIN32_WINNT = 0x0601)
typedef struct _OPM_GET_CODEC_INFO_INFORMATION {
OPM_RANDOM_NUMBER rnRandomNumber;
DWORD Merit;
@@ -273,13 +270,9 @@ typedef struct _OPM_GET_CODEC_INFO_PARAMETERS {
BYTE Verifier[OPM_GET_INFORMATION_PARAMETERS_SIZE - 4];
} OPM_GET_CODEC_INFO_PARAMETERS;
-#endif /*(_WIN32_WINNT = 0x0601)*/
-
#ifdef __cplusplus
}
#endif
-#endif /*(_WIN32_WINNT = 0x0600)*/
-
#endif /*_INC_OPMAPI*/
--
___
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: [vlc-devel] [PATCH] fix lfind errors on windows
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 in num. :( We wouldn't be dealing with random values but we should have some kind of a warning on the size limitation. To cut to the point what's the best solution here then? Remi is dead set on this being a mingw-w64 issue and not that of vlc. I submitted a patch as you can see but no hack by using #ifdef __MINGW32__ will be accepted by them, I know it's the fault of the Microsoft engineer who decided to ignore the spec. I assume that at the time they were only concerned with i686 and not x86_64 heh Thanks for your time Martell On Tue, Nov 4, 2014 at 4:44 PM, Kai Tietz ktiet...@googlemail.com wrote: 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 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 solve anything ? Many Thanks Martell On Tue, Nov 4, 2014 at 4:17 PM, Kai Tietz ktiet...@googlemail.com wrote: 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 -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] opmapi.h fixes.
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(-) -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] unexpected EOF while looking for matching `
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 the line. Take a closer look, it is a multiline entry. No where that script is and how to fix it i dont know. It is baked into gcc. Any suggestions? Where did you download your toolchain from? signature.asc Description: OpenPGP digital signature -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] unexpected EOF while looking for matching `
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 jo...@users.sourceforge.net wrote: 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 the line. Take a closer look, it is a multiline entry. No where that script is and how to fix it i dont know. It is baked into gcc. Any suggestions? Where did you download your toolchain from? -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
