automated toolchain builds

2009-04-20
2013-06-06
  • Brian Hawley
    Brian Hawley
    2009-04-20

    When will they begin again?

     
    • NightStrike
      NightStrike
      2009-04-20

      I didn't know they stopped.  I see stuff there from today.  Are you looking in the right download area?  We changed the naming conventions for the releases / packages.

       
      • Kai Tietz
        Kai Tietz
        2009-04-21

        Yeah, it is a bit irretating. NightStrike could you (hide/remove) old release packages here?

        Kai

         
    • Brian Hawley
      Brian Hawley
      2009-04-29

      Actually, I didn't drill down, just looked at the last update date on the main page, which said February.

       
    • Kai Tietz
      Kai Tietz
      2009-04-29

      We generated the package in February. Sadly SF doesn't update the date for a package, if the containing files are updated.

      Kai

       
      • clsid
        clsid
        2009-05-01

        The date gets updated when you change the package description.

        Current builds contain builds for both the GCC 4.4.0 and 4.5.0 branches. I would like to request/suggest separate toolchain packages for them. Or at least let it use the 4.4.0 binaries by default.

        Or will you guys do something like that once the "stable" toolchain builds are released?

         
        • Kai Tietz
          Kai Tietz
          2009-05-01

          Thanks for the info.

          Yes, this our snapshot folder. It works always on gcc's, binutils's, and our head version. We delete here also snapshots older then 8 days.

          This weekend we will provide toolchains for the 4.4.x series branch. They remain still in beta stage for the mingw-w64 runtime.

          We will also add (when we are convinced to have a final release version) a seperate folder for this. We plan at the moment to reach final release in September/October this year. We want to be sure our runtime works in most cases and we want to improve the build and configure of it.

          Cheers,
          Kai

           
          • clsid
            clsid
            2009-05-02

            Great to hear that.

            We are successfully using MinGW64 for several components of ffdshow, a popular DirectShow filter.

             
          • > This weekend we will provide toolchains for the 4.4.x series branch. > They remain still in beta stage for the mingw-w64 runtime.

            Where can I find the 4.4.x binary toolchains?  All I see is the source.

            Thanx!

            Chris

             
            • NightStrike
              NightStrike
              2009-05-21

              I just uploaded the linux64 hosted build.  More are forthcoming. :)

               
    • Brian Hawley
      Brian Hawley
      2009-04-29

      I defined the _M_AMD64, and proceeded with building.  I also had to manually define __x86_64__.

      Next I get a compile error:

      v:/tools/generic-i386-winxp64/mingw/include/ddk/wdm.h:1717: error: expected ')' before 'Descriptor'

      and a couple others just like it.

      This is in a section of code of an ifdef

      #if (NTDDI_VERSION >= NTDDI_VISTA)

      I'm not building for vista (nor am i building on vista) so I thought if I could find the value for NTDDI_VISTA I could set NTDDI_VERSION to something lower than that, but I can not find the definition anywhere in the headers.  So this code is getting compiled in regardless.   I surrounded it by #if 0 #endif to keep it from being compiled in.  I suspect the issue is the PIO_RESOURCE_DESCRIPTOR is somehow not getting defined.  If I include winddk.h (where it is defined) I get all sorts of errors.  So, something needs to be done differently here, I just don't know what it is.

      Next, I get ddk/winnt4.h does not exist.  I just comment out where I include this file for now.  Perhaps ReactOS has the definitions in this file elsewhere now.

      Compilation continues until

      v:/tools/generic-i386-winxp64/mingw/include/winbase.h:139: error: expected specifier-qualifier-list before 'DWORD'
      , which is referring to the DWORD Offset in the below snippet...

      typedef struct _OVERLAPPED {
         ULONG_PTR Internal;
         ULONG_PTR InternalHigh;
         __extension__ union {
           __extension__ struct {
         DWORD Offset;
         DWORD OffsetHigh;
           };
           PVOID Pointer;
         };
         HANDLE hEvent;
      } OVERLAPPED,*LPOVERLAPPED;

      But, if I don't include winbase.h, then I don't get WAIT_OBJECT_0, which I need.  For now, I have just defined WAIT_OBJECT_0 in my own files.  But this doesn't seem to be a good long term solution.  DWORD typedef'd in ddk/ntstrsafe.h to an unsigned long.  Perhaps the ReactOS expects DWORD to be defined outside of the header files?  This doesn't seem like the obvious place for a global definition of DWORD.  w32api defines DWORD in windef.h, and windef.h is included by ntddk.h.  However, while ReactOS defines them in windef.h, it also defines some basic types in ntdef.h, and ntddk includes ntdef.h.  So, these symbols don't appear to be getting defined. 

      Finally, after these hacks, I get through .c compilation, but at link time:

      c:/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.1/lib/libbase_K64.a(pal__windows.o_K64):pal__windows.c:(.text+0x192): undefined reference to `KeQuerySystemTime'
      c:/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.1/lib/libbase_K64.a(pal__windows.o_K64):pal__windows.c:(.text+0x1cf): undefined reference to `KeQuerySystemTime'
      c:/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.1/lib/libbase_K64.a(pal__windows.o_K64):pal__windows.c:(.text+0x263): undefined reference to `_imp__KfAcquireSpinLock'
      c:/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.1/lib/libbase_K64.a(pal__windows.o_K64):pal__windows.c:(.text+0x2ab): undefined reference to `_imp__KfReleaseSpinLock'
      c:/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.1/lib/libbase_K64.a(pal__windows.o_K64):pal__windows.c:(.text+0x300): undefined reference to `_imp__KfReleaseSpinLock'
      c:/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.1/lib/libbase_K64.a(pal__windows.o_K64):pal__windows.c:(.text+0x388): undefined reference to `_imp__KeInitializeSpinLock'
      c:/tmp/bhawley/generic-i386-winxp/Libraries/2.2.0.1/lib/libbase_K64.a(pal__windows.o_K64):pal__windows.c:(.text+0x5be): undefined reference to `_imp__KfAcquireSpinLock'

      I see in winddk.h for __x86_64__ they have a macro for these.  However, the section thats getting used in a build is the section with #ifdef _X86_.  I am not defining _X86_ with -D, so its getting defined by something outside of my makefiles.  Could this be getting defined by gcc in the 64 bit toolchain?  If I undef _X86_ then the build completes without the linker errors.

      And, while it does generate driver code that runs, the orignal problem with alignment of the structure that contains IoControlCode not addressed. 

      -- Brian

       
    • kosuha
      kosuha
      2009-05-12

      I am sorry to renew this thread, but I would like to ask a question about binary releases of MinGW64 for Win64 platform. There were daily builds for Windows platform earlier 'mingw-w64-bin_x86_64-mingw_xxxxxx' but now I can't find them anymore. Reading this thread I still did not get whether daily builds are canceled or it is just a temporary delay. Could you please kindly clarify. I was using MinGW64 as one of compilers for building own libs. If it is canceled will stick to building by myself from src snapshots. Would appreciate your reply.
      Thank you,
      Dmitry.

       
    • kosuha
      kosuha
      2009-05-12

      Actually latest I found is mingw-w64-bin_i686-mingw_20090420.zip, I did really missed clicking on Automated Builds and thus assumes something wrong with binary releases. Anyway this version is quite new for me and I think enough for now if stable. Thank you to the MinGW64 team for the commitment in porting of GCC under Windows. Cheers, Dmitry.

       
      • NightStrike
        NightStrike
        2009-05-12

        On April 21st, the native windows builds broke.  We're actively trying to fix that.

        Until then, enjoy the new build.  I guess I should have announced better when I changed around the whole download area :)

         
    • kosuha
      kosuha
      2009-05-13

      Thx NightStrike for response, although mingw-w64-bin_i686-mingw_20090420.zip build made my libs crashing if they are compiled with this build. E.g. application is starting up ok, but at the time of dynamic library initialisation the whole application crashes, and it happened to all 2 of them. Reverting to mingw-w64-bin_i686-mingw_20090407.zip solved the problem and libs are back operating again. Do not know if anyone else had such issue. But obviously recompiling with another (earlier) version of build solved the problem. It is offtopic report but I was delivering idea of quicker restoration of daily builds for win platform :))) joking :)) take your time anyway, there is no such necessity to update compiler on daily basis... See ya.