Re: [Mingw-w64-public] hang on exit
On 12/14/2013 03:16, Victor Bombi wrote: > Hello, > > I trying to solve a hang on program exit caused by a dll that is only seems > to be happening in my mingw64 compilation. > The program supercollider is very big so I have created a small test case in > > https://github.com/sonoro1234/hangonexit > > any help would be much appreciated > I don't think FreeLibrary will call the C++ destructors, you need to call gDiskI.~DiskIOThread manually. signature.asc Description: OpenPGP digital signature -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] hang on exit
Hello, I trying to solve a hang on program exit caused by a dll that is only seems to be happening in my mingw64 compilation. The program supercollider is very big so I have created a small test case in https://github.com/sonoro1234/hangonexit any help would be much appreciated victor -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Unable to build winpthreads DLL with GCC C compiler configured with --enable-thread=posix
2013/12/13 JonY > On 12/13/2013 22:12, Ruben Van Boxem wrote: > > Hi, > > > > I remember from a long time ago that we fixed this in the beginnings of > GCC > > posix threading, but it popped up again when I was working on a fresh set > > of build scripts to replace the old cruft I wrote and used for a couple > of > > years. > > > > Basic steps is this: > > 1. headers+binutils > > 2. GCC C (no libgcc), --enable-threads=posix > > 3. CRT > > 4. winpthreads -> fails: > > libtool: link: i686-w64-mingw32-gcc -shared > > src/.libs/libwinpthread_la-barrier.o src/.libs/libwinpthread_la-cond.o > > src/.libs/libwinpthread_la-misc.o src/.libs/libwinpthread_la-mutex.o > > src/.libs/libwinpthread_la-rwlock.o src/.libs/libwinpthread_la-spinlock.o > > src/.libs/libwinpthread_la-thread.o src/.libs/libwinpthread_la-ref.o > > src/.libs/libwinpthread_la-sem.o src/.libs/libwinpthread_la-sched.o > > src/.libs/libwinpthread_la-clock.o src/.libs/libwinpthread_la-nanosleep.o > > src/.libs/version.o -L./fakelib -O2 -o .libs/libwinpthread-1.dll > > -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker > > .libs/libwinpthread.dll.a > > > /home/ruben/cross/build/x86_64-unknown-linux-gnu/mingw32/mingw32/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/bin/ld: > > cannot find -lpthread > > collect2: error: ld returned 1 exit status > > > > Versions used: > > binutils 2.24 > > MinGW-w64 v3.0.0 > > GCC 4.8.2 > > > > Winpthreads configured with: > > --host=$target --build=$build --prefix=$prefix/$target --enable-shared > > --enable-static > > > > It seems all the right executables are being called, but a -nodefaultlibs > > is missing or something. > > > > Any ideas? Thanks! > > > > pthread is linked in implicitly when using --enable-threads=posix, you > can workaround this by introducing a dummy/empty libpthread.a before > building winpthreads, this is a way to bootstrap out of the chicken and > egg problem. > > Alternatively, you can build static pthreads first, but I don't > recommend it if you want to use libgcc dll, since you will end up with > multiple instances at runtime with static linking, not to mention, > harder to update. > Hmm, I thought this should've worked. I'll just copy libuser32.a to libpthread.a before building winpthreads. Cheers, Ruben > > > > > > -- > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Unable to build winpthreads DLL with GCC C compiler configured with --enable-thread=posix
On 12/13/2013 22:12, Ruben Van Boxem wrote: > Hi, > > I remember from a long time ago that we fixed this in the beginnings of GCC > posix threading, but it popped up again when I was working on a fresh set > of build scripts to replace the old cruft I wrote and used for a couple of > years. > > Basic steps is this: > 1. headers+binutils > 2. GCC C (no libgcc), --enable-threads=posix > 3. CRT > 4. winpthreads -> fails: > libtool: link: i686-w64-mingw32-gcc -shared > src/.libs/libwinpthread_la-barrier.o src/.libs/libwinpthread_la-cond.o > src/.libs/libwinpthread_la-misc.o src/.libs/libwinpthread_la-mutex.o > src/.libs/libwinpthread_la-rwlock.o src/.libs/libwinpthread_la-spinlock.o > src/.libs/libwinpthread_la-thread.o src/.libs/libwinpthread_la-ref.o > src/.libs/libwinpthread_la-sem.o src/.libs/libwinpthread_la-sched.o > src/.libs/libwinpthread_la-clock.o src/.libs/libwinpthread_la-nanosleep.o > src/.libs/version.o -L./fakelib -O2 -o .libs/libwinpthread-1.dll > -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker > .libs/libwinpthread.dll.a > /home/ruben/cross/build/x86_64-unknown-linux-gnu/mingw32/mingw32/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/bin/ld: > cannot find -lpthread > collect2: error: ld returned 1 exit status > > Versions used: > binutils 2.24 > MinGW-w64 v3.0.0 > GCC 4.8.2 > > Winpthreads configured with: > --host=$target --build=$build --prefix=$prefix/$target --enable-shared > --enable-static > > It seems all the right executables are being called, but a -nodefaultlibs > is missing or something. > > Any ideas? Thanks! > pthread is linked in implicitly when using --enable-threads=posix, you can workaround this by introducing a dummy/empty libpthread.a before building winpthreads, this is a way to bootstrap out of the chicken and egg problem. Alternatively, you can build static pthreads first, but I don't recommend it if you want to use libgcc dll, since you will end up with multiple instances at runtime with static linking, not to mention, harder to update. signature.asc Description: OpenPGP digital signature -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Unable to build winpthreads DLL with GCC C compiler configured with --enable-thread=posix
Hi, I remember from a long time ago that we fixed this in the beginnings of GCC posix threading, but it popped up again when I was working on a fresh set of build scripts to replace the old cruft I wrote and used for a couple of years. Basic steps is this: 1. headers+binutils 2. GCC C (no libgcc), --enable-threads=posix 3. CRT 4. winpthreads -> fails: libtool: link: i686-w64-mingw32-gcc -shared src/.libs/libwinpthread_la-barrier.o src/.libs/libwinpthread_la-cond.o src/.libs/libwinpthread_la-misc.o src/.libs/libwinpthread_la-mutex.o src/.libs/libwinpthread_la-rwlock.o src/.libs/libwinpthread_la-spinlock.o src/.libs/libwinpthread_la-thread.o src/.libs/libwinpthread_la-ref.o src/.libs/libwinpthread_la-sem.o src/.libs/libwinpthread_la-sched.o src/.libs/libwinpthread_la-clock.o src/.libs/libwinpthread_la-nanosleep.o src/.libs/version.o -L./fakelib -O2 -o .libs/libwinpthread-1.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libwinpthread.dll.a /home/ruben/cross/build/x86_64-unknown-linux-gnu/mingw32/mingw32/lib/gcc/i686-w64-mingw32/4.8.2/../../../../i686-w64-mingw32/bin/ld: cannot find -lpthread collect2: error: ld returned 1 exit status Versions used: binutils 2.24 MinGW-w64 v3.0.0 GCC 4.8.2 Winpthreads configured with: --host=$target --build=$build --prefix=$prefix/$target --enable-shared --enable-static It seems all the right executables are being called, but a -nodefaultlibs is missing or something. Any ideas? Thanks! Ruben, apparently getting back into building toolchains for some crazy reason. PS: note this time round, I am actually maintaining patches for various build issues and applying them automagically ;-) -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Win-Builds
On Fri, Dec 13, 2013, Ruben Van Boxem wrote: > 2013/12/13 Adrien Nader > > > On Fri, Dec 13, 2013, Corinna Vinschen wrote: > > > On Dec 13 10:06, Adrien Nader wrote: > > > > There are two issues here: > > > > - symlink fallback on windows > > > > - Windows XP and symlink fallback > > > > > > > > tl;dr: don't mind the warnings, they're harmless; Windows XP support is > > > > an issue (but at least read the last paragraph) > > > > > > > > Full explanation below. > > > > > > > > Since the package is a *native* windows executable, it cannot do POSIX > > > > symlinks. Win32 symlinks are slightly different and also have several > > > > issues which make them not usable. > > > > > > > > The approach to provide something equivalent to how symlinks are used > > > > inside packages is: > > > > - build on linux > > > > > > - or Cygwin. It supports its own symlinks which work on XP as well. > > > > Yes but they would require other tools to also be cygwin executables. > > > > The symlink emulation stuff is not meant for crazy things. Packages > > mostly have a simple uses for symlinks and these uses can be emulated > > through with hardlinks and junctions. > > No attempt is done to handle fancy uses or exact (or close) posix > > conformance. If that is what is wanted, cygwin is of course the right > > tool to use. > > > > Might be ignorance on my part, but why not then just let tar follow links > when creating archives? Depending on the files symlinked, that could mean > small or large size differences, but at least no hassle on your part ;-) The size difference is one of the concerns: some packages have very large documentations and copying would be quite expensive. The other, more important, issue is that some files (configuration ones in particular) are often expected to not be duplicated. Most often it would work but there are a few cases which actually rely on sharing (I don't have a list ready but I'll make sure to note down the next few ones I encounter). -- Adrien Nader -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Win-Builds
2013/12/13 Adrien Nader > On Fri, Dec 13, 2013, Corinna Vinschen wrote: > > On Dec 13 10:06, Adrien Nader wrote: > > > There are two issues here: > > > - symlink fallback on windows > > > - Windows XP and symlink fallback > > > > > > tl;dr: don't mind the warnings, they're harmless; Windows XP support is > > > an issue (but at least read the last paragraph) > > > > > > Full explanation below. > > > > > > Since the package is a *native* windows executable, it cannot do POSIX > > > symlinks. Win32 symlinks are slightly different and also have several > > > issues which make them not usable. > > > > > > The approach to provide something equivalent to how symlinks are used > > > inside packages is: > > > - build on linux > > > > - or Cygwin. It supports its own symlinks which work on XP as well. > > Yes but they would require other tools to also be cygwin executables. > > The symlink emulation stuff is not meant for crazy things. Packages > mostly have a simple uses for symlinks and these uses can be emulated > through with hardlinks and junctions. > No attempt is done to handle fancy uses or exact (or close) posix > conformance. If that is what is wanted, cygwin is of course the right > tool to use. > Might be ignorance on my part, but why not then just let tar follow links when creating archives? Depending on the files symlinked, that could mean small or large size differences, but at least no hassle on your part ;-) Cheers, Ruben > > -- > Adrien Nader > > > -- > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Win-Builds
On Fri, Dec 13, 2013, Corinna Vinschen wrote: > On Dec 13 10:06, Adrien Nader wrote: > > There are two issues here: > > - symlink fallback on windows > > - Windows XP and symlink fallback > > > > tl;dr: don't mind the warnings, they're harmless; Windows XP support is > > an issue (but at least read the last paragraph) > > > > Full explanation below. > > > > Since the package is a *native* windows executable, it cannot do POSIX > > symlinks. Win32 symlinks are slightly different and also have several > > issues which make them not usable. > > > > The approach to provide something equivalent to how symlinks are used > > inside packages is: > > - build on linux > > - or Cygwin. It supports its own symlinks which work on XP as well. Yes but they would require other tools to also be cygwin executables. The symlink emulation stuff is not meant for crazy things. Packages mostly have a simple uses for symlinks and these uses can be emulated through with hardlinks and junctions. No attempt is done to handle fancy uses or exact (or close) posix conformance. If that is what is wanted, cygwin is of course the right tool to use. -- Adrien Nader -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Compilation of wxwidgets-3 with tdm-gcc-w64 4.8.1
Hi, Some .o files are generated by windres, so you have to add "--target=pe-i386" to windres arguments in makefile.gcc. 2013/12/13 Marco N > > Dear subscribers, > > I admit that I am not an expert in using gcc/ld and especially their > flags. Anyway I used them from time time and I know how to compile basic c > codes. > I always developed in 32-bit world (x86) and I have never had issues. > I recently passed to a new system which has Win7 and 64-bit and I am > trying to compile wxWidgets-3.0 to make a pure 32-bit bin library (so > working on 32-bit systems and 64-bit). > Besides the flags that are package-specific, I'd like to exchange some > opinion about the flags I am using to try to get the package compiled and > linked. > TDM-GCC 4.8.1 claims to compile either for x64 or x86 architecture. > So this is the way I start the make. > make -f makefile.gcc > CXXFLAGS="-fnoinline-functions -m32" CPPFLAGS="-m32 -march i686" > CFLAGS="-m32 -march i686" LDFLAGS="-m32 -Ai686" RCFLAGS... > I get no errors or warnings during compilation. > The problem is that at the beginning of the linking phase I get > > c:/tdm-gcc-64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld.exe: > i386:x86-64 architecture of input file `gcc_mswuddll\monodll_version_rc.o' > is incompatible with i386 output > collect2.exe: error: ld returned 1 exit status > makefile.gcc:5202: recipe for target > '..\..\lib\gcc_dll\wxmsw30ud_gcc_custom.dll' failed > mingw32-make: *** [..\..\lib\gcc_dll\wxmsw30ud_gcc_custom.dll] Error 1 > > I really cannot get the point why monodll_version_rc.o was compiled for > x86-64 and how to force it to have i386/i686. > > Thanks in advance for your help. > -- > Marco N > > > -- > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Compilation of wxwidgets-3 with tdm-gcc-w64 4.8.1
Dear subscribers, I admit that I am not an expert in using gcc/ld and especially their flags. Anyway I used them from time time and I know how to compile basic c codes. I always developed in 32-bit world (x86) and I have never had issues. I recently passed to a new system which has Win7 and 64-bit and I am trying to compile wxWidgets-3.0 to make a pure 32-bit bin library (so working on 32-bit systems and 64-bit). Besides the flags that are package-specific, I'd like to exchange some opinion about the flags I am using to try to get the package compiled and linked. TDM-GCC 4.8.1 claims to compile either for x64 or x86 architecture. So this is the way I start the make. make -f makefile.gcc CXXFLAGS="-fnoinline-functions -m32" CPPFLAGS="-m32 -march i686" CFLAGS="-m32 -march i686" LDFLAGS="-m32 -Ai686" RCFLAGS... I get no errors or warnings during compilation. The problem is that at the beginning of the linking phase I get c:/tdm-gcc-64/bin/../lib/gcc/x86_64-w64-mingw32/4.8.1/../../../../x86_64-w64-mingw32/bin/ld.exe: i386:x86-64 architecture of input file `gcc_mswuddll\monodll_version_rc.o' is incompatible with i386 output collect2.exe: error: ld returned 1 exit status makefile.gcc:5202: recipe for target '..\..\lib\gcc_dll\wxmsw30ud_gcc_custom.dll' failed mingw32-make: *** [..\..\lib\gcc_dll\wxmsw30ud_gcc_custom.dll] Error 1 I really cannot get the point why monodll_version_rc.o was compiled for x86-64 and how to force it to have i386/i686. Thanks in advance for your help. -- Marco N-- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] ntsecapi.h: Incomplete definition of SECURITY_LOGON_SESSION_DATA
Hi Kai.. Thanks... Applied as r6420. Greetings from OneVision, Roland Kai Tietz wrote on 13.12.2013 09:58:58: > Hellor Roland, > > patch is ok. Please apply. > > Regards, > Kai > > 2013/12/12 Roland Schwingel : > > Hi... > > > > Today I discovered that the definition of SECURITY_LOGON_SESSION_DATA in > > ntsecapi.h is incomplete. It is missing several fields. > > > > Reference: http://msdn.microsoft.com/en-us/library/aa380128.aspx > > > > Also the substruct LSA_LAST_INTER_LOGON_INFO is missing. > > > > Reference: http://msdn.microsoft.com/en-us/library/hh920949.aspx > > > > The attached patch adds support for these things. > > > > These fields (and LSA_LAST_INTER_LOGON_INFO) have been added in XP SP2 > > (desktop) or 2008(server) - according to msdn. > > > > I made a test. It seems to be true that 2003 does not support this at all. > > So to be on the safe side I have encapsulated support for these "new" things > > with #if (_WIN32_WINNT >= 0x0600) as it cannot be guaranteed on compiletime > > to have a sane XP (means SP2 or better) or 2008 server present at the same > > time. > > > > I hope this can be applied cleanly. Thanks. > > > > Roland -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Win-Builds
On Dec 13 10:06, Adrien Nader wrote: > There are two issues here: > - symlink fallback on windows > - Windows XP and symlink fallback > > tl;dr: don't mind the warnings, they're harmless; Windows XP support is > an issue (but at least read the last paragraph) > > Full explanation below. > > Since the package is a *native* windows executable, it cannot do POSIX > symlinks. Win32 symlinks are slightly different and also have several > issues which make them not usable. > > The approach to provide something equivalent to how symlinks are used > inside packages is: > - build on linux - or Cygwin. It supports its own symlinks which work on XP as well. Corinna -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Win-Builds
On Fri, Dec 13, 2013, wynfi...@gmail.com wrote: > > > It doesn't look like the mklink command is available to the XP based systems. > > I've found two possible substitute command, ln and junction, available at: > > ln .. http://schinagl.priv.at/nt/ln/ln.html#introduction > junction .. http://technet.microsoft.com/en-gb/sysinternals/bb896768 > > Could either of these be used as a fix to enable XP install win-builds? Their syntax is not the same as far as I remember so they're not drop-in replacements and I think the tool from sysinternals cannot be redistributed without restriction. The 'ln' tool you linked to also has restrictions because of some libraries it uses. Since I need to write some more code to handle removal of directory junctions, these probably won't be needed. I'll try to have a go at that this week-end. -- Adrien Nader -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Win-Builds
Hi,
On Fri, Dec 13, 2013, wynfi...@gmail.com wrote:
>
> Sorry I did not provide details:
>
> Building environment: Microsoft XP SP3 (Japanese Home Edition)
>
> Fetech http://win-builds.org/stable/win-builds-bundle-1.3-beta3.zip
> Into local download dir:..some_path/win-builds
>
> Started cmd.exe
> Changed directory the ..some_path/win-builds
>
> #did
> set YYPREFIX=C:/win-builds-32
> yypkg -init
> yypkg -config -setpreds host="i686-w64-mingw32"
> yypkg -config -setpreds target="i686-w64-mingw32"
> sherpa -set-mirror http://win-builds.org/1.3-beta3/packages/windows_32
> sherpa -install all
>
> # the below is what I earlier sent
> cat fa wrote:
> > When I did sherpa -install all, nothong was downloaded.
>
> When I ran:
> $ sherpa -install all
>
> It installed nearly everthing I think. Hoever, it aborted with the followi=
> ng error message.
> #1
> Installing gtk+2-2.24.20-1-i686-w64-mingw32.txz...mklink
> ... external command ( original was in Japanese char set so I added english )
> ... not recognized as an executable or batch file.
> Fatal error: exception Failure(""mklink /J
> \"doc/gtk+-2.24.20/gail-libgail-util\
> " \"doc\\gtk+-2.24.20/../../share/gtk-doc/html/gail-libgail-util\"" returned 1
> .")
>
>
> Also there were numerous messages related to "skipping" symbolic links whic=
> h I don't
> know if these are important or not. There presence did not halt the insta=
> ll process.
> #2=20=20
> Installing fontconfig-2.10.93-1-i686-w64-mingw32.txz...Skipping symlink
> "etc/fon
> ts/conf.d/10-scale-bitmap-fonts.conf" ->
> "../../../../../../../opt/windows_32/et
> c/fonts/conf.avail/10-scale-bitmap-fonts.conf": ENOENT
> Skipping symlink "share/fontconfig/conf.avail" ->
> "../../../../../../opt/windows
> _32/etc/fonts/conf.avail": ENOENT
> DONE
>
There are two issues here:
- symlink fallback on windows
- Windows XP and symlink fallback
tl;dr: don't mind the warnings, they're harmless; Windows XP support is
an issue (but at least read the last paragraph)
Full explanation below.
Since the package is a *native* windows executable, it cannot do POSIX
symlinks. Win32 symlinks are slightly different and also have several
issues which make them not usable.
The approach to provide something equivalent to how symlinks are used
inside packages is:
- build on linux
- before building the package, build a list of symlinks and store the
filetype of the target: directory, regular file or unknown (unhandled)
- build the package with the symlinks excluded
- when installing, extract the files from the package
- if on windows, emulate symlinks with:
- hardlinks for links to regular files
- directory junctions for links to directories
- skip and print a message for unknown ones
The "Skipping symlink" line is because of that last case. The additional
ENOENT means that the type of the target is unknown because the symlink
was broken when creating the package (it might be not-broken when
actually installed but it's not something that is handled yet).
I've checked again all of the "unhandled" symlinks and I see none that
break functionality. The breakdown is roughly:
- gfortran-related symlinks which shouldn't exist
reported as http://win-builds.org/bugs/index.php?do=details&task_id=15
- symlinks inside "share/doc"
- the fontconfig ones you've seen above; I'm not sure they matter but
I'll check
- a symlink from /lib/cpp to /usr/bin/cpp which probably only matters to
linux distributions
Currently, symlinks to directories are handled through a tool named
"mklink.exe". It is a command-line tool to create hardlinks, symlinks
and directory junctions but it is not on Windows XP.
The quick-and-easy solution is to copy that file from another machine
but it's not something I can redistribute myself.
The other solution is that yypkg stops using mklink.exe. This wasn't
done before because writing some C (yypkg isn't written in C) is
required in order to access some very win32-specific APIs to both create
and delete directory junctions. It's not very difficult; it's simply
something that hasn't been done yet.
This is actually also required because calling unlink() on directory
junctions fails with EPERM (cmd.exe's del and msys1's rm happen to also
fail removing directory junctions; explorer does it fine). The
corresponding item in the bug tracker is:
http://win-builds.org/bugs/index.php?do=details&task_id=13&project=2
(NB: version "1.7" and "1.8" are yypkg versions, not win-builds one)
With that said, I don't know how much attention should be given to
Windows XP nowadays. It's going to not be updated by MS anymore in 4
months and I wasn't really expecting someone on this mailing-list to
still use Windows XP on a daily basis to be honest.
I'm going to fix the aforementionned issue. However I don't know how
much attention should be given to this OS and that's because I don't
know how man
Re: [Mingw-w64-public] ntsecapi.h: Incomplete definition of SECURITY_LOGON_SESSION_DATA
Hellor Roland, patch is ok. Please apply. Regards, Kai 2013/12/12 Roland Schwingel : > Hi... > > Today I discovered that the definition of SECURITY_LOGON_SESSION_DATA in > ntsecapi.h is incomplete. It is missing several fields. > > Reference: http://msdn.microsoft.com/en-us/library/aa380128.aspx > > Also the substruct LSA_LAST_INTER_LOGON_INFO is missing. > > Reference: http://msdn.microsoft.com/en-us/library/hh920949.aspx > > The attached patch adds support for these things. > > These fields (and LSA_LAST_INTER_LOGON_INFO) have been added in XP SP2 > (desktop) or 2008(server) - according to msdn. > > I made a test. It seems to be true that 2003 does not support this at all. > So to be on the safe side I have encapsulated support for these "new" things > with #if (_WIN32_WINNT >= 0x0600) as it cannot be guaranteed on compiletime > to have a sane XP (means SP2 or better) or 2008 server present at the same > time. > > I hope this can be applied cleanly. Thanks. > > Roland > > -- > Rapidly troubleshoot problems before they affect your business. Most IT > organizations don't have a clear picture of how application performance > affects their revenue. With AppDynamics, you get 100% visibility into your > Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics > Pro! > http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Win-Builds
Hi, On Fri, Dec 13, 2013, cat fa wrote: > When I did sherpa -install all, nothong was downloaded. Most likely you didn't set the predicates (right). Predicates are these two lines in the documentation: yypkg -config -setpreds host="i686-w64-mingw32" yypkg -config -setpreds target="i686-w64-mingw32" (or x86_64-w64-mingw32 if you install for 64b toolchains with the "windows_64" repo) They are free-form: both key and value can be set when creating a package. If a value is set in the package, the same value has to be set in the config of the package manager when installing. You should probably run these commands again as it's fairly easy to have a typo somewhere in the strings and since they are free-form, no coherency check can be done when setting them. By the way, this feature is meant to avoid mixing repositories and installing packages for one architecture while packages for another one are actually wanted. This can happen mostly when installing packages by hand. However installing by hand is not the common case and it might make sense to automatically set the predicates from the package repository that is selected. I need to think a bit more about it but that would be nice and probably wouldn't make the check less efficient. In any case, I've added a message in sherpa which will print the number of packages that are valid after filtering through the predicates. This should make it much easier to understand what is going on. (I'm also going to add a FAQ to make the message something that can be looked up on a search engine) This will be available in the next update. Thanks. Regards, Adrien Nader -- Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
