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 =/ > -- > Ozkan > ------------------------------------------------------------------------------ _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
