On 4 May 2010 10:40, JonY <[email protected]> wrote: > On 5/4/2010 17:08, Dmitrijs Ledkovs wrote: >> >> On 4 May 2010 10:03, Ozkan Sezer<[email protected]> wrote: >>> >>> On Tue, May 4, 2010 at 10:53 AM, Dmitrijs Ledkovs >>> <[email protected]> wrote: >>>> >>>> On 4 May 2010 07:51, Ozkan Sezer<[email protected]> wrote: >>>>> >>>>> On Tue, May 4, 2010 at 9:44 AM, Dmitrijs Ledkovs >>>>> <[email protected]> wrote: >>>>>> >>>>>> the patch link from documentation doesn't apply from me. >>>>>> >>>>>> neither against tarball nor against cvs please help. >>>>> >>>>> Is the patch from here? >>>>> >>>>> http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/patches/pthreads_win32/ >>>>> >>>>> That one applies to the CVS version of pthreads perfectly. >>>>> Otherwise, if you are running on windows, you might have >>>>> hit some dos line endigns issue?? >>>>> >>>> >>>> Ok =) let me state what I need better =) >>>> >>>> I want two more patches ontop of that one: >>>> >>>> how it looks after the sed magic has been applied to make it's >>>> GNUMakefile ready for building i686 and second one for x86_64 >>>> >>>> So when I'm building for i686 i would apply that one from the link& >>>> i686_prep.patch; >>>> When building for x86_64 patch from the link above and& >>>> x86_64_prep.patch >>>> >>>> I'm having troubles with running the makebuildroot-test.mk to create >>>> those for me. >>>> >>> >>> I don't have experience with that buildbot makefile, however I can >>> not find any reference to a i686_prep.patch or x86_64_prep.patch in >>> it, either. If your problem is that a second sed magic (such as for >>> prep'ing it for x86_64) not working on the GNUmakefile once a first >>> one (such as for prep'ing for i686) is applied, you should always >>> work on a backup copy of the original GNUmakefile the one resulting >>> from the applying of w64sup.patch. >>> >>> My own scripts has something like: >>> >>> cvs -z9 -d:pserver:[email protected]:/cvs/pthreads-win32 co pthreads >>> cd pthreads >>> patch -p1< ../pthreads-w64sup.patch >>> cp -p config.h pthreads_win32_config.h >>> cp -p pthread.h pthread.h.bak >>> sed -e 's/HAVE_CONFIG_H/1/' \ >>> -e 's/config.h/pthreads_win32_config.h/' \ >>> < pthread.h.bak>pthread.h >>> cp -p GNUmakefile GNUmakefile.bak >>> >>> The resulting source tree at this point is my reference. >>> >>> Then, for x86_64-w64-mingw32 I do: >>> >>> sed -e 's/dlltool$/& -m i386:x86-64/' \ >>> -e 's/gcc$/& -m64/' \ >>> -e 's/g++$/& -m64/' \ >>> -e 's/windres$/& -F pe-x86-64/' \ >>> -e 's/pthreadGC\$(DLL_VER)/&-w64/g' \ >>> -e 's/pthreadGCE\$(DLL_VER)/&-w64/g' \ >>> < GNUmakefile.bak> GNUmakefile >>> make CROSS="x86_64-w64-mingw32-" clean GC >>> >>> ... and then for i686-w64-mingw32, I do: >>> >>> sed -e 's/dlltool$/& -m i386/' \ >>> -e 's/gcc$/& -m32/' \ >>> -e 's/g++$/& -m32/' \ >>> -e 's/windres$/& -F pe-i386/' \ >>> -e 's/pthreadGC\$(DLL_VER)/&-w32/g' \ >>> -e 's/pthreadGCE\$(DLL_VER)/&-w32/g' \ >>> < GNUmakefile.bak> GNUmakefile >>> make CROSS="i686-w64-mingw32-" clean GC >>> >>> As you see, I always do the sed magic on the backup GNUmakefile.bak >>> and output a new GNUmakefile for every new target. >>> >>> Hope these help. >>> >> >> Yeap thanks.the -test makefile a bit more obsuscated and whey i tried >> to run just the mangling target it started to checkout binutils =/ >> > > Hi, > > I wrote the -test makefile, its designed to build everything from binutils > to the crt to gcc. Ozkan's script is quite similar to the one in the -test > makefile. > > Are you trying to build only pthreads? >
I have a working jhbuilder xml file which can at your option to pull sources from git,bzr mirrors, tarballs or upstream svn/cvs. It can build individual parts (updateone / buildone) or it can build the whole thing. The biggest difference is that it builds both toolchains which are coinstallable & it removes duplicate things which would clash if unpackacked into /usr. Overall it is more robust and faster due to local git or bazaar mirrors. Also I have working debian packaging which is build from bzr branch and is easily updatable with any versions of the toolchain parts. The default is to build-depend on the distribution provided patched source tarballs unpack those at buildtime in the distribution autobuilders and build the whole toolchain alternativly a branch of binutils & gcc can be merge to build the tips of gcc/binutils imports in launchpad ppa. Both methods currently produce co-installable 2 cross toolchains either from stable releases or upstream svn's. The current defficiencies are that I'm not building bohem to get java compiler & i don't have pthreads yet for the additonal feature in the gcc. Both methods produce relocatable toolchains such that you can grab the deb package unpack it and use it after setting the path correct. Yesterday I got the binutils to be build with --enable-shared which greatly reduced their size. Additional caveat is that pascal is failing to build on x86_64 due to failing debian "helpful" check of finding somehow that one function is assuming that sizeof(prt*) == sizeof(int) the build succeeeds creates deb package and then it fails the build so that I can't actually download them. You can see the fullbuildlog here: https://launchpad.net/~dmitrij.ledkov/+archive/ppa/+build/1712824/+files/buildlog_ubuntu-lucid-amd64.mingw-w64_2.20.1+2.1_FAILEDTOBUILD.txt.gz the current 2 debian packages for both targets on x86_64 linux host are 85MiB compressed with lzma. I think i can make it smaller. I was going to do a formal announcement when i get: pthread (easy), bohem (medium), pascal (wtf is going on) & stripping binaries (easy) finished. The idea is to run daily builds on launchpad & upload this updated toolchain to superseed mingw* packages in debian & ubuntu. Status update I guess..... ------------------------------------------------------------------------------ _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
