[Mingw-w64-public] REPARSE_DATA_BUFFER seems to be missing
Hello, While attempting to use Ruben's GCC 4.6.2 build under Windows 7 to compile libuv [1], I found that REPARSE_DATA_BUFFER is undefined: gcc -Iinclude -Iinclude/uv-private -g --std=gnu89 -D_WIN32_WINNT=0x0501 -Isrc/ares/config_win32 -o src/win/fs.o -c src/win/fs.c src/win/fs.c: In function 'fs__readlink': src/win/fs.c:696:3: error: unknown type name 'REPARSE_DATA_BUFFER' src/win/fs.c:735:19: error: 'REPARSE_DATA_BUFFER' undeclared (first use in this function) src/win/fs.c:735:19: note: each undeclared identifier is reported only once for each function it appears in src/win/fs.c:735:39: error: expected expression before ')' token The definition is here [2] and I found it in ddk/ntfis.h but couldn't find a clear way to also search for ddk directory. I'm missing a way to trigger the inclusion of DDK? Thank you. [1] https://github.com/joyent/libuv/ [2] http://msdn.microsoft.com/en-us/library/windows/hardware/ff552012(v=vs.85).aspx -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exupéry -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] REPARSE_DATA_BUFFER seems to be missing
On Wed, Oct 19, 2011 at 10:45 AM, Luis Lavena luislav...@gmail.com wrote: On Wed, Oct 19, 2011 at 9:32 AM, Ozkan Sezer seze...@gmail.com wrote: On Wed, Oct 19, 2011 at 10:23 AM, Luis Lavena luislav...@gmail.com wrote: I'm missing a way to trigger the inclusion of DDK? Doing #include ntifs.h in your *.c and -I[somepath]/ddk in your CFLAGS or something? Thank you, Problem with that is means I would have to hardcode a path into the Makefile that only applies to my environment. But, perhaps is the only alternative. You can use some environment variables pointing to the ddk headers path, and in your Makefile you can do, like: ifeq ($(DDK_PATH),) DDK_PATH=someplace endif CFLAGS+=-I$(DDK_PATH) Thank you. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exupéry -- O.S. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] REPARSE_DATA_BUFFER seems to be missing
Op 19 okt. 2011 10:07 schreef Ozkan Sezer seze...@gmail.com het volgende: On Wed, Oct 19, 2011 at 10:45 AM, Luis Lavena luislav...@gmail.com wrote: On Wed, Oct 19, 2011 at 9:32 AM, Ozkan Sezer seze...@gmail.com wrote: On Wed, Oct 19, 2011 at 10:23 AM, Luis Lavena luislav...@gmail.com wrote: I'm missing a way to trigger the inclusion of DDK? Doing #include ntifs.h in your *.c and -I[somepath]/ddk in your CFLAGS or something? Why not ddk/ntifs.h? Shouldn't the ddk headers be in a standard include directory by default? Thank you, Problem with that is means I would have to hardcode a path into the Makefile that only applies to my environment. But, perhaps is the only alternative. You can use some environment variables pointing to the ddk headers path, and in your Makefile you can do, like: ifeq ($(DDK_PATH),) DDK_PATH=someplace endif CFLAGS+=-I$(DDK_PATH) Thank you. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exupéry -- O.S. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] REPARSE_DATA_BUFFER seems to be missing
On Wed, Oct 19, 2011 at 12:25 PM, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: Op 19 okt. 2011 10:07 schreef Ozkan Sezer seze...@gmail.com het volgende: On Wed, Oct 19, 2011 at 10:45 AM, Luis Lavena luislav...@gmail.com wrote: On Wed, Oct 19, 2011 at 9:32 AM, Ozkan Sezer seze...@gmail.com wrote: On Wed, Oct 19, 2011 at 10:23 AM, Luis Lavena luislav...@gmail.com wrote: I'm missing a way to trigger the inclusion of DDK? Doing #include ntifs.h in your *.c and -I[somepath]/ddk in your CFLAGS or something? Why not ddk/ntifs.h? Shouldn't the ddk headers be in a standard include directory by default? Uhm, were trying to be M$-ish, that's all :) Thank you, Problem with that is means I would have to hardcode a path into the Makefile that only applies to my environment. But, perhaps is the only alternative. You can use some environment variables pointing to the ddk headers path, and in your Makefile you can do, like: ifeq ($(DDK_PATH),) DDK_PATH=someplace endif CFLAGS+=-I$(DDK_PATH) Thank you. -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exupéry -- O.S. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] REPARSE_DATA_BUFFER seems to be missing
On Wed, Oct 19, 2011 at 11:25 AM, Ruben Van Boxem vanboxem.ru...@gmail.com wrote: Op 19 okt. 2011 10:07 schreef Ozkan Sezer seze...@gmail.com het volgende: Doing #include ntifs.h in your *.c and -I[somepath]/ddk in your CFLAGS or something? Why not ddk/ntifs.h? Shouldn't the ddk headers be in a standard include directory by default? Thing is that ddk/ntifs.h depends on other .h files which will require be prefixed (#include ddk/something.h) Thank you both for your input, will check with other developers what they would like to do for this. Regards, -- Luis Lavena AREA 17 - Perfection in design is achieved not when there is nothing more to add, but rather when there is nothing more to take away. Antoine de Saint-Exupéry -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [Qt-interest] Memory exhausted ld error when building Qt 4.8.0-rc1 with mingw-w64 4.7.0
Hello Lists! I get the following error: ./tmp\obj\debug_shared\moc_qgraphicsanchorlayout.o: file not recognized: Memory exhausted in the build step that links QtGuid4.dll when trying to build Qt 4.8.0-rc1 with mingw-w64 4.7.0 Would anyone have some suggestions about how I might fix this? (Task manager reported over 2 GB of available memory after the failed build process exited. I don't know how much memory was in use during the build.) Would it be possible to configure the Qt build process slightly differently? Would there be some way to run the offending link command manually, maybe tweaking it a little, and then continuing with the build process? I am trying to build Qt 4.8.0-rc1: qt-everywhere-opensource-src-4.8.0-rc1.zip with the mighty Ruben's std::thread-enabled 4.7.0 mingw-w64 build: x86_64-w64-mingw32-gcc-4.7.0-stdthread_rubenvb.7z I am running on 64-bit windows 7. I ran the configure step for Qt thus: configure -opensource -platform win32-g++ -debug-and-release Note, I did have to patch the typo in pthread.h (tm -- ___tmp_tm) to get past an earlier build error, as described in an earlier thread on this list: http://sourceforge.net/mailarchive/message.php?msg_id=28124842 Here's the background on what I'm trying to accomplish: I want to upgrade various parts of my development environment. I am hoping to use a late-model g++ (hence the 4.7.0) to get as much support for the new c++11 as I can. I specifically want support for std::thread (hence Ruben's std::thread-enabled build). I decided to give Qt 4.8.0 a try (rather than upgrading, for example, to Qt 4.7.4) for no compelling reason, but I figured why not. I can dial back on either the compiler or the Qt version, or downgrade to 32 bits from 64 bits, for that matter, to fix the problem, but my general goal in the upgrade is to push forward as much as possible, A little more detail: The specific link command (from running mingw32-make) that fails is: g++ -mthreads -shared -Wl,--out-implib,c:\qt\4.8.0-rc1\lib\libQtGuid4.a -o ..\..\lib\QtGuid4.dll object_script.QtGuid.Debug -Lc:\qt\4.8.0-rc1\lib -Lc:\qt\4.8.0-rc1\lib -lgdi32 -lcomdlg32 -loleaut32 -limm32 -lwinmm -lwinspool -lws2_32 -lole32 -l uuid -luser32 -ladvapi32 tmp\obj\debug_shared\QtGuid_resource_res.o -lmsimg32 -lshell32 -lQtCored4 The resulting error message is: ./tmp\obj\debug_shared\moc_qgraphicsanchorlayout.o: file not recognized: Memory exhausted collect2.exe: error: ld returned 1 exit status mingw32-make[2]: *** [..\..\lib\QtGuid4.dll] Error 1 For what it's worth (I doubt it matters), this failed link command occurs immediately after the windres command for compiling QtGuid_resource_res.o: windres -i QtGuid_resource.rc -o tmp\obj\debug_shared\QtGuid_resource_res.o --include-dir=. -DQT_SHARED -DQT_THREAD_SUPPORT -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_BUILD_GUI_LIB -DQT_NO_USING_NAMESPACE -DQT_MAKEDLL -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -D_USE_MATH_DEFINES -DQT_NO_DIRECTDRAW -DQT_USE_BUNDLED_LIBPNG -DPNG_NO_ASSEMBLER_CODE -DQT_NO_CUPS -DQT_NO_LPR -DQT_NO_OPENTYPE -DQT_NO_STYLE_MAC -DQT_NO_STYLE_GTK -DQT_NO_STYLE_WINDOWSCE -DQT_NO_STYLE_WINDOWSMOBILE -DQT_NO_STYLE_S60 -DQT_NO_EGL -DQ_INTERNAL_QAPP_SRC -DQT_NO_DIRECTWRITE -DQT_DLL -DQT_CORE_LIB -DQT_HAVE_MMX -DQT_HAVE_3DNOW -DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 Thanks for everyone's thoughts and advice. K. Frank -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Qt-interest] Memory exhausted ld error when building Qt 4.8.0-rc1 with mingw-w64 4.7.0
于 2011/10/19 22:32, K. Frank 写道: Hello Lists! I get the following error: ./tmp\obj\debug_shared\moc_qgraphicsanchorlayout.o: file not recognized: Memory exhausted in the build step that links QtGuid4.dll when trying to build Qt 4.8.0-rc1 with mingw-w64 4.7.0 Would anyone have some suggestions about how I might fix this? (Task manager reported over 2 GB of available memory after the failed build process exited. I don't know how much memory was in use during the build.) Would it be possible to configure the Qt build process slightly differently? Would there be some way to run the offending link command manually, maybe tweaking it a little, and then continuing with the build process? I am trying to build Qt 4.8.0-rc1: qt-everywhere-opensource-src-4.8.0-rc1.zip with the mighty Ruben's std::thread-enabled 4.7.0 mingw-w64 build: x86_64-w64-mingw32-gcc-4.7.0-stdthread_rubenvb.7z I am running on 64-bit windows 7. I ran the configure step for Qt thus: configure -opensource -platform win32-g++ -debug-and-release Note, I did have to patch the typo in pthread.h (tm -- ___tmp_tm) to get past an earlier build error, as described in an earlier thread on this list: http://sourceforge.net/mailarchive/message.php?msg_id=28124842 Here's the background on what I'm trying to accomplish: I want to upgrade various parts of my development environment. I am hoping to use a late-model g++ (hence the 4.7.0) to get as much support for the new c++11 as I can. I specifically want support for std::thread (hence Ruben's std::thread-enabled build). I decided to give Qt 4.8.0 a try (rather than upgrading, for example, to Qt 4.7.4) for no compelling reason, but I figured why not. I can dial back on either the compiler or the Qt version, or downgrade to 32 bits from 64 bits, for that matter, to fix the problem, but my general goal in the upgrade is to push forward as much as possible, A little more detail: The specific link command (from running mingw32-make) that fails is: g++ -mthreads -shared -Wl,--out-implib,c:\qt\4.8.0-rc1\lib\libQtGuid4.a -o ..\..\lib\QtGuid4.dll object_script.QtGuid.Debug -Lc:\qt\4.8.0-rc1\lib -Lc:\qt\4.8.0-rc1\lib -lgdi32 -lcomdlg32 -loleaut32 -limm32 -lwinmm -lwinspool -lws2_32 -lole32 -l uuid -luser32 -ladvapi32 tmp\obj\debug_shared\QtGuid_resource_res.o -lmsimg32 -lshell32 -lQtCored4 The resulting error message is: ./tmp\obj\debug_shared\moc_qgraphicsanchorlayout.o: file not recognized: Memory exhausted collect2.exe: error: ld returned 1 exit status mingw32-make[2]: *** [..\..\lib\QtGuid4.dll] Error 1 For what it's worth (I doubt it matters), this failed link command occurs immediately after the windres command for compiling QtGuid_resource_res.o: windres -i QtGuid_resource.rc -o tmp\obj\debug_shared\QtGuid_resource_res.o --include-dir=. -DQT_SHARED -DQT_THREAD_SUPPORT -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_BUILD_GUI_LIB -DQT_NO_USING_NAMESPACE -DQT_MAKEDLL -DQT_NO_CAST_TO_ASCII -DQT_ASCII_CAST_WARNINGS -DQT3_SUPPORT -DQT_MOC_COMPAT -DQT_USE_QSTRINGBUILDER -D_USE_MATH_DEFINES -DQT_NO_DIRECTDRAW -DQT_USE_BUNDLED_LIBPNG -DPNG_NO_ASSEMBLER_CODE -DQT_NO_CUPS -DQT_NO_LPR -DQT_NO_OPENTYPE -DQT_NO_STYLE_MAC -DQT_NO_STYLE_GTK -DQT_NO_STYLE_WINDOWSCE -DQT_NO_STYLE_WINDOWSMOBILE -DQT_NO_STYLE_S60 -DQT_NO_EGL -DQ_INTERNAL_QAPP_SRC -DQT_NO_DIRECTWRITE -DQT_DLL -DQT_CORE_LIB -DQT_HAVE_MMX -DQT_HAVE_3DNOW -DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 Thanks for everyone's thoughts and advice. K. Frank Try to add -fno-keep-inline-dllexport to your compiler option. -- Best Regards, xunxun -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Qt-interest] Memory exhausted ld error when building Qt 4.8.0-rc1 with mingw-w64 4.7.0
于 2011/10/19 23:18, Ruben Van Boxem 写道: reduce DLL size reduce DLL obj size -- Best Regards, xunxun -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Qt-interest] Memory exhausted ld error when building Qt 4.8.0-rc1 with mingw-w64 4.7.0
于 2011/10/19 23:38, Morcego Vermelho 写道: this answer is enigmatic I dont know how to reduce it If you refer to Qt build, you can modify mkspecs/win32-g++/qmake.conf (similar it is, I forgot that) QMAKE_CFLAGS_RELEASE = -O2 -fno-keep-inline-dllexport -- Best Regards, xunxun -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2d-oct___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Qt-interest] Memory exhausted ld error when building Qt 4.8.0-rc1 with mingw-w64 4.7.0
2011/10/19 K. Frank kfrank2...@gmail.com Hello xunxun! On Wed, Oct 19, 2011 at 11:43 AM, xunxun xunxun1...@gmail.com wrote: 于 2011/10/19 23:38, Morcego Vermelho 写道: ... If you refer to Qt build, you can modify mkspecs/win32-g++/qmake.conf (similar it is, I forgot that) QMAKE_CFLAGS_RELEASE = -O2 -fno-keep-inline-dllexport Thank you. I will give this a try. In my case I am trying to build both the debug and release versions. Is there a corresponding flag I should set for the debug version. (It appears that my Memory exhausted error is occurs during the debug part of the build process.) Am I right that to do this I edit qmake.conf by hand? Would anyone know offhand whether I should be doing this before or after I run the initial configure step? After the initial configure step, because that runs qmake on all of Qt. On the page file size: that seems ok. I didn't modify the Windows defaults. I'm still kind of dazzled by this, I never encountered it. Another kind of functionality impeding workaround is to remove the -g command in qmake.conf to *not* generate any debug info. This will remove the ability to step in/through Qt functions though. Another small thing is adding -Wl,--no-keep-memory,--reduce-memory-overheads to the linker command line (in qmake.conf). Legend goes it reduces ld's memory usage by ~200MB. I haven't tried it yet. If you're interested in binutils bugs about this, see: http://sourceware.org/bugzilla/show_bug.cgi?id=12658 (hmm, seems there aren't any others... probably a hard problem to pinpoint in a bug report) Ruben ... Best Regards, xunxun Thanks. I appreciate your advice. K. Frank -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [Qt-interest] Memory exhausted ld error when building Qt 4.8.0-rc1 with mingw-w64 4.7.0
Hi, K. Frank On Thu, Oct 20, 2011 at 1:54 AM, K. Frank kfrank2...@gmail.com wrote: Hello xunxun! On Wed, Oct 19, 2011 at 11:43 AM, xunxun xunxun1...@gmail.com wrote: 于 2011/10/19 23:38, Morcego Vermelho 写道: ... If you refer to Qt build, you can modify mkspecs/win32-g++/qmake.conf (similar it is, I forgot that) QMAKE_CFLAGS_RELEASE = -O2 -fno-keep-inline-dllexport Thank you. I will give this a try. In my case I am trying to build both the debug and release versions. Is there a corresponding flag I should set for the debug version. (It appears that my Memory exhausted error is occurs during the debug part of the build process.) This is very similar. You can also modify the qmake.conf QMAKE_CFLAGS_DEBUG= -g -fno-keep-inline-dllexport (should be QMAKE_CFLAGS_DEBUG? I forgot it, too...) Am I right that to do this I edit qmake.conf by hand? Would anyone know offhand whether I should be doing this before or after I run the initial configure step? ... Best Regards, xunxun Thanks. I appreciate your advice. K. Frank -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Best Regards, xunxun -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Ciosco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
