From: <ch...@gm...> - 2008-01-19 09:34:28
|
I'm trying to compile a version of gcc(let me call it=20 mingw-gcc.ro-linux), which means the resulting gcc runs on Linux and=20 generate Win32 PE executables running on MS Windows (ro means run-on here= ). I use SuSE Linux 10.3 as the build machine, and I download the following = packages from=20 sf.net(http://sourceforge.net/project/showfiles.php?group_id=3D2435): 1. gcc-4.2.1-2-src.tar.gz (Technology Preview: gcc-4.2.1-mingw-src-2=20 <showfiles.php?group_id=3D2435&package_id=3D241304&release_id=3D538041> N= otes=20 <shownotes.php?release_id=3D538041&group_id=3D2435> (2007-08-14 04:05) ).= I=20 think it contains gcc & g++ source code tweaked from offical gcc.gnu.org = =2E 2. mingw-runtime-3.13.tar.gz (Previous Release: mingw-runtime-3.13=20 <showfiles.php?group_id=3D2435&package_id=3D11598&release_id=3D84152> Not= es=20 <shownotes.php?release_id=3D84152&group_id=3D2435> (2007-08-25 06:53)) 3. w32api-3.10.tar.gz (Previous Release: w32api-3.10=20 <showfiles.php?group_id=3D2435&package_id=3D11550&release_id=3D15085> Not= es=20 <shownotes.php?release_id=3D15085&group_id=3D2435> (2007-08-03 06:42) ) I extract above 2 & 3 to /usr/local/i686-mingw32 . I did not download the lastest version of mingw-runtime etc because I=20 think those something old packages are all from Aug 2007 which may match = better. I configure gcc as follows( in dir /soft/mingw/build ). =2E./gcc-4.2.1-2-src/configure \ --enable-languages=3Dc,c++ \ --with-gcc --with-gnu-ld --with-gnu-as --with-stabs \ --disable-nls\ --target=3Di686-mingw32 \ then the command, make all-gcc After a long run, I got error: /soft/mingw/build/./gcc/xgcc -B/soft/mingw/build/./gcc/ -L/soft/mingw/bui= ld/i686-mingw32/winsup/mingw -L/soft/mingw/build/i686-mingw32/winsup/w32a= pi/lib -isystem /soft/mingw/gcc-4.2.1-2-src/winsup/mingw/include -isystem= /soft/mingw/gcc-4.2.1-2-src/winsup/w32api/include -B/usr/local/i686-ming= w32/bin/ -B/usr/local/i686-mingw32/lib/ -isystem /usr/local/i686-mingw32/= include -isystem /usr/local/i686-mingw32/sys-include -O2 -O2 -g -O2 -DIN= _GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmis= sing-prototypes -Wold-style-definition -isystem ./include -I. -I. -I../= =2E./gcc-4.2.1-2-src/gcc -I../../gcc-4.2.1-2-src/gcc/. -I../../gcc-4.2.1-= 2-src/gcc/../include -I../../gcc-4.2.1-2-src/gcc/../libcpp/include -I../= =2E./gcc-4.2.1-2-src/gcc/../libdecnumber -I../libdecnumber -g0 -finhibit= -size-directive -fno-inline-functions -fno-exceptions -fno-zero-initializ= ed-in-bss -fno-toplevel-reorder -Dinhibit_libc -fno-omit-frame-pointer -c= -o crtbegin.o \ ../../gcc-4.2.1-2-src/gcc/config/i386/cygming-crtbegin.c =2E./../gcc-4.2.1-2-src/gcc/config/i386/cygming-crtbegin.c:72: error: sec= tion attribute not allowed for '__JCR_LIST__' Now, why cygming-crtbegin.c fails to compile ? I found a mail in mailing list saying the similar question, but seems no = answer. http://lists-archives.org/mingw-users/07971-results.html Please help me out. Thank you in advance. - |
From: Brian D. <br...@de...> - 2008-01-19 10:45:21
|
"Chen (?) Jun (?)" wrote: > ../../gcc-4.2.1-2-src/gcc/config/i386/cygming-crtbegin.c:72: error: section attribute not allowed for '__JCR_LIST__' > > Now, why cygming-crtbegin.c fails to compile ? Did you build a cross-binutils and install it in the PATH before building gcc? Brian |
From: <ch...@gm...> - 2008-01-19 11:45:53
|
Brian Dessent 写道: > "Chen (?) Jun (?)" wrote: > > >> ../../gcc-4.2.1-2-src/gcc/config/i386/cygming-crtbegin.c:72: error: section attribute not allowed for '__JCR_LIST__' >> >> Now, why cygming-crtbegin.c fails to compile ? >> > > Did you build a cross-binutils and install it in the PATH before > building gcc? > > Brian > > Not yet. I know that binutils should be built sooner or later, but just like to take an adventure to see what will stop me if binutils was built later than ``make all-gcc' . Thank you Brian and I'll try your suggestion first, but could you tell me why a properly installed binutils can eliminate that error? Anyhow, I can't have any hint that the above compile error is caused by lack of binutils. You know, we can know that mingw-runtime is not present if [ stdio.h is not found on compiling cygming-crtbegin.c . |
From: Brian D. <br...@de...> - 2008-01-19 14:48:36
|
"Chen (?) Jun (?)" wrote: > Not yet. I know that binutils should be built sooner or later, but just > like to take an adventure to see what will stop me if binutils was built > later than ``make all-gcc' . It's not optional. binutils contains the assembler and linker, without which gcc cannot actually do anything, as gcc itself is nothing more than a glorified text processor. > Thank you Brian and I'll try your suggestion first, but could you tell > me why a properly installed binutils can eliminate that error? Anyhow, I It looks like it's using the host assembler instead of the cross assembler because configure couldn't find a suitable cross assembler in the path. While both Linux and MinGW may run on the same hardware, the ELF 'as' and the PE 'as' are quite different in syntax and capabilities. It's probably failing here because this is the first target code it tried to compile, and thus the first time the cross-as would have been required. (Everything before that is host code, and is built with the host tools.) Brian |
From: <ch...@gm...> - 2008-01-19 15:48:11
|
Brian Dessent 写道: > "Chen (?) Jun (?)" wrote: > > >> Not yet. I know that binutils should be built sooner or later, but just >> like to take an adventure to see what will stop me if binutils was built >> later than ``make all-gcc' . >> > > It's not optional. binutils contains the assembler and linker, without > which gcc cannot actually do anything, as gcc itself is nothing more > than a glorified text processor. > > >> Thank you Brian and I'll try your suggestion first, but could you tell >> me why a properly installed binutils can eliminate that error? Anyhow, I >> > > It looks like it's using the host assembler instead of the cross > assembler because configure couldn't find a suitable cross assembler in > the path. While both Linux and MinGW may run on the same hardware, the > ELF 'as' and the PE 'as' are quite different in syntax and > capabilities. It's probably failing here because this is the first > target code it tried to compile, and thus the first time the cross-as > would have been required. (Everything before that is host code, and is > built with the host tools.) > > Brian > > Thank you for your kind answer, Brian. But it seems not to be the case you have expected. Now I tell you what I just did. I grab binutils-2.17.50-20060824-1-src.tar.gz <http://downloads.sourceforge.net/mingw/binutils-2.17.50-20060824-1-src.tar.gz?modtime=1199663565&big_mirror=1> from sf.net mingw section, extract it to */soft/mingw/binutils-2.17.50-20060824-1-src* , issue the following three commands in /soft/mingw/build-bintuils : ../binutils-2.17.50-20060824-1-src/configure --prefix=/soft/binutils-host-linux-target-win32 --target=i686-mingw32 \ --disable-nls --with-gcc --with-gnu-as --with-gnu-ld --with-stabs \ 2>&1 | tee binutils_configure.log make all 2>&1 | tee binutils_make.log make install 2>&1 | tee binutils_install.log This process runs OK, and i686-mingw32-ld etc are generated . Now, I cd back to /soft/mingw/build , write a shell script #!/bin/sh PATH=/soft/binutils-host-linux-target-win32/bin:$PATH make all-gcc | tee make-c-only.log 2>&1 and run it. Ooups, same error result as before I build binutils. DIAGNOSE: Let's recall the compile error message I encountered: ../../gcc-4.2.1-2-src/gcc/config/i386/cygming-crtbegin.c:72: error: section attribute not allowed for '__JCR_LIST__' It looks like this error happens when xgcc translate a .c to an .s unit, that is, before i686-mingw32-as or i686-mingw32-ld is called. Can a clean of ``make gcc-all''s output help? I hope you can give me more hint before I do that, since my computer is no so fast and it cost 40 minutes in ``make gcc-all'' before it encounters this error. |
From: Earnie B. <ea...@us...> - 2008-01-19 16:26:41
|
Quoting "Chen (=E9=99=88) Jun (=E5=86=9B)" <ch...@gm...>: > > This process runs OK, and i686-mingw32-ld etc are generated . Now, I cd > back to /soft/mingw/build , write a shell script > > #!/bin/sh > PATH=3D/soft/binutils-host-linux-target-win32/bin:$PATH > make all-gcc | tee make-c-only.log 2>&1 > > > and run it. Ooups, same error result as before I build binutils. > > DIAGNOSE: Let's recall the compile error message I encountered: > > ../../gcc-4.2.1-2-src/gcc/config/i386/cygming-crtbegin.c:72: > error: section attribute not allowed for '__JCR_LIST__' > > You'll have to start over. I.E. You must reexecute configure for gc in a clean build directory so that your make system knows about your newly built binutils. Earnie |
From: <ch...@gm...> - 2008-01-19 17:01:45
|
Earnie Boyd 写道: > Quoting "Chen (陈) Jun (军)" <ch...@gm...>: > > >> This process runs OK, and i686-mingw32-ld etc are generated . Now, I cd >> back to /soft/mingw/build , write a shell script >> >> #!/bin/sh >> PATH=/soft/binutils-host-linux-target-win32/bin:$PATH >> make all-gcc | tee make-c-only.log 2>&1 >> >> >> and run it. Ooups, same error result as before I build binutils. >> >> DIAGNOSE: Let's recall the compile error message I encountered: >> >> ../../gcc-4.2.1-2-src/gcc/config/i386/cygming-crtbegin.c:72: >> error: section attribute not allowed for '__JCR_LIST__' >> > > You'll have to start over. I.E. You must reexecute configure for gc in > a clean build directory so that your make system knows about your newly > built binutils. > > Earnie > > Thank you Earine. I will try that, and could you help check if my gcc configure options are correct? ../gcc-4.2.1-2-src/configure \ --enable-languages=c,c++ \ --with-gcc --with-gnu-ld --with-gnu-as --with-stabs \ --disable-nls\ --target=i686-mingw32 \ Must I add --prefix= to where I have installed my binutils? BTW, Can I enable c,c++ both at once to make gcc & g++ out in one shot? I heard somewhere g++ should be built at a second run. Is that right? |
From: Henry N. <hen...@ar...> - 2008-01-19 21:38:23
|
Chen (陈) Jun (军) wrote: > Earnie Boyd 写道: >> Quoting "Chen (陈) Jun (军)" <ch...@gm...>: >> >> >>> This process runs OK, and i686-mingw32-ld etc are generated . Now, I cd >>> back to /soft/mingw/build , write a shell script >>> >>> #!/bin/sh >>> PATH=/soft/binutils-host-linux-target-win32/bin:$PATH >>> make all-gcc | tee make-c-only.log 2>&1 >>> >>> >>> and run it. Ooups, same error result as before I build binutils. >>> >>> DIAGNOSE: Let's recall the compile error message I encountered: >>> >>> ../../gcc-4.2.1-2-src/gcc/config/i386/cygming-crtbegin.c:72: >>> error: section attribute not allowed for '__JCR_LIST__' >>> >> You'll have to start over. I.E. You must reexecute configure for gc in >> a clean build directory so that your make system knows about your newly >> built binutils. >> >> Earnie >> >> > Thank you Earine. I will try that, and could you help check if my gcc > configure options are correct? > > ../gcc-4.2.1-2-src/configure \ > --enable-languages=c,c++ \ > --with-gcc --with-gnu-ld --with-gnu-as --with-stabs \ > --disable-nls\ > --target=i686-mingw32 \ > > Must I add --prefix= to where I have installed my binutils? Yes, you should use prefix to same place as your binutils. Prefix will be use for installing this gcc later. The error to build the gcc not depens on installation of binutils you build before, because the host binutils are used in this step. You build the gcc to use on Linux in this case. In this step the binutils for "target" are not used. Be shure, that your host 'gcc' and 'as' is in PATH not the target: which gcc gcc --version which as as --version Your target should be "i686-Name-mingw32". The middle is the name of your free choice, the 3th must be the target platform. I use typicaly --target=i686-pc-mingw. I got it ready from source of gcc 4.2.2 with follow config: ../gcc-4.2.2/configure -v --prefix=/home/user/binutils-2.17.50-gcc422 --target=i686-pc-mingw32 --with-headers=/home/user/binutils-2.17.50-gcc422/i686-pc-mingw32/include --with-gnu-as --with-gnu-ld --disable-nls --without-newlib --disable-multilib --enable-languages=c,c++ --disable-checking Binutils 2.17.50-20070129-1 build and installed before on same prefix. gcc 4.2.0 have build in same way, gcc 4.2.1 have not tested. -- Henry |
From: Keith M. <kei...@us...> - 2008-01-19 22:17:20
|
On Saturday 19 January 2008 21:39, Henry Nestler wrote: > Your target should be "i686-Name-mingw32". The middle is the name of > your free choice, the 3th must be the target platform. I use typicaly > --target=i686-pc-mingw. Typically yes, but the vendor name isn't strictly necessary; it should be sufficient to specify just CPU and OS, as in `i[3456]86-mingw32'. Regards, Keith. |
From: <ch...@gm...> - 2008-01-20 06:46:58
|
Henry Nestler wrote: > Chen (陈) Jun (军) wrote: > >> Earnie Boyd 写道: >> >>> Quoting "Chen (陈) Jun (军)" <ch...@gm...>: >>> >>> >>> >>>> This process runs OK, and i686-mingw32-ld etc are generated . Now, I cd >>>> back to /soft/mingw/build , write a shell script >>>> >>>> #!/bin/sh >>>> PATH=/soft/binutils-host-linux-target-win32/bin:$PATH >>>> make all-gcc | tee make-c-only.log 2>&1 >>>> >>>> >>>> and run it. Ooups, same error result as before I build binutils. >>>> >>>> DIAGNOSE: Let's recall the compile error message I encountered: >>>> >>>> ../../gcc-4.2.1-2-src/gcc/config/i386/cygming-crtbegin.c:72: >>>> error: section attribute not allowed for '__JCR_LIST__' >>>> >>>> >>> You'll have to start over. I.E. You must reexecute configure for gc in >>> a clean build directory so that your make system knows about your newly >>> built binutils. >>> >>> Earnie >>> >>> >>> >> Thank you Earine. I will try that, and could you help check if my gcc >> configure options are correct? >> >> ../gcc-4.2.1-2-src/configure \ >> --enable-languages=c,c++ \ >> --with-gcc --with-gnu-ld --with-gnu-as --with-stabs \ >> --disable-nls\ >> --target=i686-mingw32 \ >> >> Must I add --prefix= to where I have installed my binutils? >> > > Yes, you should use prefix to same place as your binutils. Prefix will > be use for installing this gcc later. > OK. Thanks. > The error to build the gcc not depens on installation of binutils you > build before, because the host binutils are used in this step. You build > the gcc to use on Linux in this case. In this step the binutils for > "target" are not used. > Hi, Henry, I read your above paragraph three times and still can't get the point. Will you clarify this? By the way, please use proper tense when you express your meaning. > Be shure, that your host 'gcc' and 'as' is in PATH not the target: > which gcc > gcc --version > which as > as --version > Of course, until now, never have I set /soft/binutils-host-linux-target-win32/i686-mingw32/bin in my PATH env-var, where there are 'as', 'ld' etc which operate on Win32 binares. > Your target should be "i686-Name-mingw32". The middle is the name of > your free choice, the 3th must be the target platform. I use typicaly > --target=i686-pc-mingw. > > I got it ready from source of gcc 4.2.2 with follow config: > ../gcc-4.2.2/configure -v --prefix=/home/user/binutils-2.17.50-gcc422 > --target=i686-pc-mingw32 > --with-headers=/home/user/binutils-2.17.50-gcc422/i686-pc-mingw32/include > --with-gnu-as --with-gnu-ld --disable-nls --without-newlib > --disable-multilib --enable-languages=c,c++ --disable-checking > > Binutils 2.17.50-20070129-1 build and installed before on same prefix. > gcc 4.2.0 have build in same way, gcc 4.2.1 have not tested. > > |
From: Henry N. <hen...@ar...> - 2008-01-20 13:21:01
|
Chen (陈) Jun (军) wrote: > Henry Nestler wrote: >> Chen (陈) Jun (军) wrote: >> >>> Earnie Boyd 写道: >>> >>>> Quoting "Chen (陈) Jun (军)" <ch...@gm...>: >>>> >>>> >>>> >>>>> This process runs OK, and i686-mingw32-ld etc are generated . Now, I cd >>>>> back to /soft/mingw/build , write a shell script >>>>> >>>>> #!/bin/sh >>>>> PATH=/soft/binutils-host-linux-target-win32/bin:$PATH >>>>> make all-gcc | tee make-c-only.log 2>&1 >>>>> >>>>> >>>>> and run it. Ooups, same error result as before I build binutils. >>>>> >>>>> DIAGNOSE: Let's recall the compile error message I encountered: >>>>> >>>>> ../../gcc-4.2.1-2-src/gcc/config/i386/cygming-crtbegin.c:72: >>>>> error: section attribute not allowed for '__JCR_LIST__' >>>>> >>>>> >>>> You'll have to start over. I.E. You must reexecute configure for gc in >>>> a clean build directory so that your make system knows about your newly >>>> built binutils. >>>> >>>> Earnie >>>> >>>> >>>> >>> Thank you Earine. I will try that, and could you help check if my gcc >>> configure options are correct? >>> >>> ../gcc-4.2.1-2-src/configure \ >>> --enable-languages=c,c++ \ >>> --with-gcc --with-gnu-ld --with-gnu-as --with-stabs \ >>> --disable-nls\ >>> --target=i686-mingw32 \ >>> >>> Must I add --prefix= to where I have installed my binutils? >>> >> Yes, you should use prefix to same place as your binutils. Prefix will >> be use for installing this gcc later. >> > OK. Thanks. >> The error to build the gcc not depens on installation of binutils you >> build before, because the host binutils are used in this step. You build >> the gcc to use on Linux in this case. In this step the binutils for >> "target" are not used. >> > Hi, Henry, I read your above paragraph three times and still can't get > the point. Will you clarify this? By the way, please use proper tense > when you express your meaning. The line, you posted was from compiler, not from linker. The source was a *.c file and the output is a *.o file. Thats, I mean the linker is not involved at this point, and you got the same error with and without binutils. I have read your first post again and saw, you used an other gcc source tree. You used the patched gcc from mingw project. I use the vanilla gcc from ftp://ftp.gnu.org/gnu/gcc/gcc-4.2.2 the files gcc-core-4.2.2.tar.bz2 and gcc-g++-4.2.2.tar.bz2 without Java and other stuff. For linux as host this can be the difference. My building for cross gcc with host linux and target mingw32 based on the coLinux project. There you can see all the steps. The scripts you can download from SVN http://colinux.svn.sourceforge.net/svnroot/colinux/branches/devel/bin/build-cross.sh http://colinux.svn.sourceforge.net/svnroot/colinux/branches/devel/bin/build-common.sh http://colinux.svn.sourceforge.net/svnroot/colinux/branches/devel/bin/sample.user-build.cfg In the scrips gcc 4.1.2 is currently used. Have running the same scripts with gcc 4.2.2, the patch (changing version numbers) have here http://www.henrynestler.com/colinux/patches/devel/gcc-4.2.2-binutils-2.18.50.patch Mingw scripts x86-mingw32-build.sh does not work for me with gcc 4.2.2 -- Henry |
From: <ch...@gm...> - 2008-01-20 09:39:06
|
Earnie Boyd wrote: > Quoting "Chen (陈) Jun (军)" <ch...@gm...>: > > > >> This process runs OK, and i686-mingw32-ld etc are generated . Now, I cd >> back to /soft/mingw/build , write a shell script >> >> #!/bin/sh >> PATH=/soft/binutils-host-linux-target-win32/bin:$PATH >> make all-gcc | tee make-c-only.log 2>&1 >> >> >> and run it. Ooups, same error result as before I build binutils. >> >> DIAGNOSE: Let's recall the compile error message I encountered: >> >> ../../gcc-4.2.1-2-src/gcc/config/i386/cygming-crtbegin.c:72: >> error: section attribute not allowed for '__JCR_LIST__' >> > You'll have to start over. I.E. You must reexecute configure for gc in > a clean build directory so that your make system knows about your newly > built binutils. > > Earnie > > I tried. You're dead right Earnie. I clean the output file generated during compling my i686-mingw32-gcc, and configure again according to Henry Nestler's suggestion. ../gcc-4.2.1-2-src/configure -v --prefix=/soft/binutils-host-linux-target-win32 \ --target=i686-mingw32 \ --with-headers=/soft/mingw/binutils-2.17.50-20060824-1-src/include \ --with-gnu-as --with-gnu-ld --disable-nls --without-newlib \ --disable-multilib --enable-languages=c,c++ --disable-checking \ 2>&1 | tee chj-cfg-host-linux-target-mingw2.log Then run again (chj-build-mingw-gcc.ro-linux2.sh): #!/bin/sh PATH=/soft/binutils-host-linux-target-win32/bin:$PATH make all-gcc | tee make-c-only.log2 2>&1 make install-gcc Cheers, i686-mingw32-gcc is out and works(tested with simple hello world program). After taking a review, I observed that the ./configure of gcc's result is different before and after binutils is installed. Before, there are: checking for ar... no checking for i686-mingw32-ar... no checking for as... no checking for i686-mingw32-as... no checking for dlltool... no checking for i686-mingw32-dlltool... no checking for ld... no checking for i686-mingw32-ld... no After, there are: checking for ar... /soft/binutils-host-linux-target-win32/i686-mingw32/bin/ar checking for as... /soft/binutils-host-linux-target-win32/i686-mingw32/bin/as checking for dlltool... /soft/binutils-host-linux-target-win32/i686-mingw32/bin/dlltool checking for ld... /soft/binutils-host-linux-target-win32/i686-mingw32/bin/ld Wow, it really makes difference, and only the later is the correct result. However my baffle is not entirely resolved. Why the above difference makes my first try fail(xgcc fail to compile cygming-crtbegin.c)? I compared the two xgcc before and after, they really are different, but different at what aspect? Can anyone give more comments? |
From: Michael G. <mg...@ti...> - 2008-01-19 11:43:19
|
> I'm trying to compile a version of gcc(let me call it=20 > mingw-gcc.ro-linux), which means the resulting gcc runs on Linux and=20 > generate Win32 PE executables running on MS Windows (ro means run-on here= ). You might be interested in http://sourceforge.net/project/showfiles.php?group_id=3D2435&package_id=3D1= 2644 > I found a mail in mailing list saying the similar question, but seems no= =20 > answer. http://lists-archives.org/mingw-users/07971-results.html >=20 > Please help me out. Thank you in advance. As Brian already pointed out, you need to create a xbinutils first. Searching http://lists-archives.org/mingw-users for 'xcompiler' yields several postings, many of which might interest you, e.g. http://lists-archives.org/mingw-users/09235-problem-creating-linux-hosted-m= ingw-xcompiler-4-2-x.html Just recently there have been a couple of threads dealing with this very topic (i.e. building xcompiler etc.). =46inally there is an entry in the MinGWiki dealing with it, albeit somewhat outdated. However the basic ideas are still valid. HTH, Michael =2D-=20 Michael Gerdau email: mg...@ti... GPG-keys available on request or at public keyserver |
From: <ch...@gm...> - 2008-01-19 12:19:29
|
Michael Gerdau 写道: > You might be interested in > http://sourceforge.net/project/showfiles.php?group_id=2435&package_id=12644 > > Thank you. It might be helpful, but I'd like to try it manually. For a monster piece of constantly evolving software like gcc, I don't think a automatic script can do everthing I need. |
From: Michael G. <mg...@ti...> - 2008-01-19 12:56:10
|
> Thank you. It might be helpful, but I'd like to try it manually. For a=20 > monster piece of constantly evolving software like gcc, I don't think a=20 > automatic script can do everthing I need. Just out of curiosity: What is it that you think can't be automated and what do you think is so special about your requirements re building gcc that defies automation ? Best, Michael =2D-=20 Michael Gerdau email: mg...@ti... GPG-keys available on request or at public keyserver |
From: <ch...@gm...> - 2008-01-19 13:50:30
|
Michael Gerdau 写道: >> Thank you. It might be helpful, but I'd like to try it manually. For a >> monster piece of constantly evolving software like gcc, I don't think a >> automatic script can do everthing I need. >> > > Just out of curiosity: > What is it that you think can't be automated and what do you think is > so special about your requirements re building gcc that defies > automation ? > > Best, > Michael > As many many people know, buiding gcc is complex, it requires many pieces of source packages(gcc itself, binutils, glibc/mingw-runtime etc). And I've heard that there are subtle, dependencies betweens these packages, that is, you cannot just grab a gcc version later than 2.95 and any binutils version, any glibc and make them built up. -- What's more, things are more complex when you want to build a cross compiler. So when I want a specific gcc version to use, I have to care a lot and try a lot. Frankly speaking, my recent ultimate goal is to build a mingw-flavor gcc compiler(gcc/g++.exe runs with Windows' native CRT) which generates arm-elf images(the so-called canadian cross). I searched Internet recently and did not find a stock compiler like that(only found www.gnuarm.com which provide cygwin hosted arm-elf compiler). So I deem it a hard way. So I'd like to try it solid. As first step of my goal, I think I should build the so-called mingw-gcc.ro-linux variant of gcc, and so why this thread comes. |
From: Michael G. <mg...@ti...> - 2008-01-19 17:49:14
|
> As many many people know, buiding gcc is complex, it requires many=20 > pieces of source packages(gcc itself, binutils, glibc/mingw-runtime=20 > etc). To some extend that may be correct. But then...may be not. > And I've heard that there are subtle, dependencies betweens these =20 > packages, that is, you cannot just grab a gcc version later than 2.95=20 > and any binutils version, any glibc and make them built up. Why not ? There may be subtle issues with certain special combinations. As a general rule your above statement does not seem to be correct. > So when I want a specific gcc version to use, I have to care a lot and=20 > try a lot. Is that so ?! > Frankly speaking, my recent ultimate goal is to build a =20 > mingw-flavor gcc compiler(gcc/g++.exe runs with Windows' native CRT)=20 > which generates arm-elf images(the so-called canadian cross). That much I guessed from what I've read so far. > I searched =20 > Internet recently and did not find a stock compiler like that(only found= =20 > www.gnuarm.com which provide cygwin hosted arm-elf compiler). Did you find our set of scripts to create a xcompiler ? If not then maybe your searching could go with an improvement ! > So I'd like to try it solid. Be my guest. I repeat my previously given advice: Check out what we provide. That includes our set of scripts as well as reading the appropriate articles in MinGWiki and the archives of this list. NONE of what you have said you wish to achive is particularly new for quite a few of us. Of course you are welcome to learn everything from ground up yourself, try out every cul de sac etc. etc. HTH, Michael =2D-=20 Michael Gerdau email: mg...@ti... GPG-keys available on request or at public keyserver |
From: <ch...@gm...> - 2008-01-20 03:52:33
|
Michael Gerdau 写道: >> I searched >> Internet recently and did not find a stock compiler like that(only found >> www.gnuarm.com which provide cygwin hosted arm-elf compiler). >> > > Did you find our set of scripts to create a xcompiler ? > If not then maybe your searching could go with an improvement ! > > >> So I'd like to try it solid. >> > > Be my guest. > > I repeat my previously given advice: > Check out what we provide. That includes our set of scripts as well as > reading the appropriate articles in MinGWiki and the archives of this > list. > > NONE of what you have said you wish to achive is particularly new for > quite a few of us. Of course you are welcome to learn everything from > ground up yourself, try out every cul de sac etc. etc. > > HTH, > Michael > > Well, Michael, I still have some questions. In the last day, you refer me to two scripts. * First, http://downloads.sourceforge.net/mingw/x86-mingw32-build.sh-0.0-20061107-1.tar.bz2 * Second, may be this: http://www.mingw.org/MinGWiki/index.php/this%20shell-Script (it says you are the current maintainer of it.) I have a glance at these scripts, they're written in quite different flavor. Which one should I use, both are OK? The second question: I tried x86-mingw32-build.sh-0.0-20061107-1.tar.bz2 , and feel I'd better try it sometime later, because I use gcc 4.2.1 source from gcc-4.2.1-2-src.tar.gz <http://downloads.sourceforge.net/mingw/gcc-4.2.1-2-src.tar.gz?modtime=1187089509&big_mirror=1>(Technology Preview: gcc-4.2.1-mingw-src-2 <showfiles.php?group_id=2435&package_id=241304&release_id=538041> Notes <shownotes.php?release_id=538041&group_id=2435> (2007-08-14 04:05) ). its name does not match the pattern gcc-core-X.Y.X-src.tar.gz, and more, it contains gcc & g++ sources tweaked an packed together, which makes the script not suitable on the fly -- I think. If you know the difference between gcc-4.2.1-2-src.tar.gz <http://downloads.sourceforge.net/mingw/gcc-4.2.1-2-src.tar.gz?modtime=1187089509&big_mirror=1>and [ gcc-core-4.2.1-src.gz , gcc-g++-4.2.1-src.gz ], and which one is more suitable to build a mingw-gcc, please tell me. Thank you. |
From: Brian D. <br...@de...> - 2008-01-20 09:53:28
|
"Chen (?) Jun (?)" wrote: > However my baffle is not entirely resolved. Why the above difference > makes my first try fail(xgcc fail to compile cygming-crtbegin.c)? I > compared the two xgcc before and after, they really are different, but > different at what aspect? > > Can anyone give more comments? The configure script does a number of feature tests on the assembler and linker to see what the platform supports, to enable various functionality. It appears it enabled something that ELF supports since it was actually testing the host assembler, but which PE does not support. I don't think that Java class registration section stuff has been ported to PE, but I could be wrong. Brian |
From: Michael G. <mg...@ti...> - 2008-01-21 08:35:22
|
> Well, Michael, I still have some questions. Well, Chen, let's see whether I can provide answers. > In the last day, you refer me to two scripts. > * First,=20 > http://downloads.sourceforge.net/mingw/x86-mingw32-build.sh-0.0-20061107-= 1.tar.bz2=20 >=20 > * Second, may be this:=20 > http://www.mingw.org/MinGWiki/index.php/this%20shell-Script (it says you= =20 > are the current maintainer of it.) > > I have a glance at these scripts, they're written in quite different=20 > flavor. Which one should I use, both are OK? Reread what I wrote: I repeatedly referred you to the first script. In one mail I also wrote Finally there is an entry in the MinGWiki dealing with it, albeit somewhat outdated. However the basic ideas are still valid. The second script obviously comes from the Wiki. Now comes the $10,000.00 question: Which one should you use ? Are you able to answer it ? [hint: read _carefully_] > The second question: >=20 > I tried x86-mingw32-build.sh-0.0-20061107-1.tar.bz2 , and feel I'd=20 > better try it sometime later, because I use gcc 4.2.1 source from=20 > gcc-4.2.1-2-src.tar.gz=20 > <http://downloads.sourceforge.net/mingw/gcc-4.2.1-2-src.tar.gz?modtime=3D= 1187089509&big_mirror=3D1>(Technology=20 > Preview: gcc-4.2.1-mingw-src-2=20 > <showfiles.php?group_id=3D2435&package_id=3D241304&release_id=3D538041> N= otes=20 > <shownotes.php?release_id=3D538041&group_id=3D2435> (2007-08-14 04:05) ).= =20 > its name does not match the pattern gcc-core-X.Y.X-src.tar.gz, and=20 > more, it contains gcc & g++ sources tweaked an packed together, which=20 > makes the script not suitable on the fly -- I think. Again: Reread what I wrote. To speed up your searching, here it is again: several postings, many of which might interest you, e.g. http://lists-archives.org/mingw-users/09235-problem-creating-linux-hosted= =2Dmingw-xcompiler-4-2-x.html Just recently there have been a couple of threads dealing with this very topic (i.e. building xcompiler etc.). Apparently you have not bothered to look at any of it. BTW: Both these scripts (as all other scripts been adverticed by others in this thread) do build binutils before gcc. Having used any of these would have solved your original problem. Most of what you learned the hard way you could have learned by looking at these scripts. > If you know the difference between gcc-4.2.1-2-src.tar.gz =20 > <http://downloads.sourceforge.net/mingw/gcc-4.2.1-2-src.tar.gz?modtime=3D= 1187089509&big_mirror=3D1>and=20 > [ gcc-core-4.2.1-src.gz , gcc-g++-4.2.1-src.gz ], and which one is more=20 > suitable to build a mingw-gcc, please tell me. Thank you. The difference is twofold. a) any package gcc-<someversion>.tar.gz is the whole distribution while the packages gcc-<component>-someversion>.tar.gz only have the code required for that component. All component packages together are the same as the complete package. [this is basic gcc packaging information available by trivial search as well as easily derived by a little bit of thinking and possibly looking into the archives] b) the packages available at gcc.gnu.org are the original packages as released by the FSF. The packages on our site are the original gcc packages with some mingw specific patches applied on top. 8AFAIK this also is easily available information thought currently sitting in a train I can't verify that] Anyway I assume you now are able to answer your above question which of these packages is more suiteable to build a mingw-gcc. [again a hint: Read carefully] To sum it up: Most of your problems and questions have been answered one or the other way by several people repeatedly. You consistently chose to ignore advice given to you. That's a perfectly valid decision you are entitled to make. The problems start creaping in when you fail because you ignored the given advice and start asking already answered questions. Then you do wasting others time by going the easy way of asking questions instead of doing basic research for yourself. Again that is your decision. It consequently is my decision to ignore your future posts unless you actually have done your homeworks. Best, Michael =2D-=20 Michael Gerdau email: mg...@ti... GPG-keys available on request or at public keyserver |
From: <ch...@gm...> - 2008-01-21 13:49:34
|
On 1/21/08, Michael Gerdau <mg...@ti...> wrote: > > > Well, Michael, I still have some questions. > > Well, Chen, let's see whether I can provide answers. > > > In the last day, you refer me to two scripts. > > * First, > > > http://downloads.sourceforge.net/mingw/x86-mingw32-build.sh-0.0-20061107-1.tar.bz2 > > > > * Second, may be this: > > http://www.mingw.org/MinGWiki/index.php/this%20shell-Script (it says you > > are the current maintainer of it.) > > > > I have a glance at these scripts, they're written in quite different > > flavor. Which one should I use, both are OK? > > Reread what I wrote: > I repeatedly referred you to the first script. In one mail I also wrote > > Finally there is an entry in the MinGWiki dealing with it, albeit > somewhat outdated. However the basic ideas are still valid. > > The second script obviously comes from the Wiki. > > Now comes the $10,000.00 question: > Which one should you use ? > > Are you able to answer it ? > [hint: read _carefully_] > > > The second question: > > > > I tried x86-mingw32-build.sh-0.0-20061107-1.tar.bz2 , and feel I'd > > better try it sometime later, because I use gcc 4.2.1 source from > > gcc-4.2.1-2-src.tar.gz > > < > http://downloads.sourceforge.net/mingw/gcc-4.2.1-2-src.tar.gz?modtime=1187089509&big_mirror=1 > >(Technology > > Preview: gcc-4.2.1-mingw-src-2 > > <showfiles.php?group_id=2435&package_id=241304&release_id=538041> Notes > > <shownotes.php?release_id=538041&group_id=2435> (2007-08-14 04:05) ). > > its name does not match the pattern gcc-core-X.Y.X-src.tar.gz, and > > more, it contains gcc & g++ sources tweaked an packed together, which > > makes the script not suitable on the fly -- I think. > > Again: > Reread what I wrote. To speed up your searching, here it is again: > several postings, many of which might interest you, e.g. > > http://lists-archives.org/mingw-users/09235-problem-creating-linux-hosted-mingw-xcompiler-4-2-x.html > > Just recently there have been a couple of threads dealing with this very > topic (i.e. building xcompiler etc.). > > Apparently you have not bothered to look at any of it. > > BTW: > Both these scripts (as all other scripts been adverticed by others in > this thread) do build binutils before gcc. Having used any of these > would have solved your original problem. Most of what you learned the > hard way you could have learned by looking at these scripts. > > > If you know the difference between gcc-4.2.1-2-src.tar.gz > > < > http://downloads.sourceforge.net/mingw/gcc-4.2.1-2-src.tar.gz?modtime=1187089509&big_mirror=1 > >and > > [ gcc-core-4.2.1-src.gz , gcc-g++-4.2.1-src.gz ], and which one is more > > suitable to build a mingw-gcc, please tell me. Thank you. > > The difference is twofold. > a) any package gcc-<someversion>.tar.gz is the whole distribution while > the packages gcc-<component>-someversion>.tar.gz only have the code > required for that component. All component packages together are the > same as the complete package. > [this is basic gcc packaging information available by trivial search as > well as easily derived by a little bit of thinking and possibly looking > into the archives] > > b) the packages available at gcc.gnu.org are the original packages as > released by the FSF. The packages on our site are the original gcc > packages with some mingw specific patches applied on top. > 8AFAIK this also is easily available information thought currently > sitting in a train I can't verify that] > > Anyway I assume you now are able to answer your above question which of > these packages is more suiteable to build a mingw-gcc. > [again a hint: Read carefully] > > > To sum it up: > Most of your problems and questions have been answered one or the other > way by several people repeatedly. You consistently chose to ignore > advice given to you. That's a perfectly valid decision you are entitled > to make. > > The problems start creaping in when you fail because you ignored the given > advice and start asking already answered questions. Then you do wasting > others time by going the easy way of asking questions instead of doing > basic research for yourself. > > Again that is your decision. > > It consequently is my decision to ignore your future posts unless you > actually have done your homeworks. > > Best, > Michael > -- > > > Well, Michael, I think you're a responsible person, and I thank you for your spending time replying to me. But you understood me deeply, so I have to clarify it. As many persons who wants to build gcc themselve, I do not want just a working gcc in front of me, I want to get to know how to build gcc step by step as well as whant's going on in there, therefore, an automated script that prepares everything for me is not what I want now. After I start this mail thread, Brian and you answered me first, both suggesting that I should build binutils first. And I repied to Brian that I will now try building binutils. Then how can you say I "consistently chose to ignore advice given to me"? As I pointed out in my first reply to Brian, I said I " just like to take an adventure to see what will stop me if binutils was built later than ``make all-gcc' ". Why I said so? Because I can hardly find information telling me explicitly for what reason binutils must be built before all-gcc". So, I'd like to take an adventure(old saying "Nothing ventured, nothing gained.", you know) to build gcc before binutils , see what error information will I get when the failure occurs, and curiously wish to find out whether that error info contains any hint telling the error is due to missing target binutils. Unfortunately, as I had discovered later, no such hint, but the weired "section attribute not allowed for '__JCR_LIST__'" ! Wouldn't it be better if the build process could fail at a more reasonable stage and with a more reasonalble error message? Finally, I'm responsible for the topic I provoked too. I present my final experiment result to this discussion thread ( http://lists-archives.org/mingw-users/09455-help-cross-compile-cygming-crtbegin-c-compile-error.html). Regards. |
From: Keith M. <kei...@us...> - 2008-01-21 21:16:58
|
On Monday 21 January 2008 13:49, Chen(=E9=99=88) Jun(=E5=86=9B) wrote: > Michael Gerdau wrote: > > It consequently is my decision to ignore your future posts unless > > you actually have done your homeworks. > > > Well, Michael, I think you're a responsible person, and I thank you > for your spending time replying to me. But you understood me deeply, > so I have to clarify it. Michael, Chen (or is your given name Jun?), this to-and-fro bickering=20 about who is, or is not paying attention to whom, benefits no one. > As many persons who wants to build gcc themselve, I do not want just > a working gcc in front of me, You want to learn how to build it for yourself; that's an admirable=20 goal, and we fully understand and applaud it. > I want to get to know how to build gcc step by step as well as whant's > going on in there, And an excellent way to achieve that is by studying the way others have=20 done it before you; our existing scripts provide you with ample study=20 material for that. > therefore, an automated script that prepares everything for me is not > what I want now. Really? Not even as a study resource? He who refuses to learn from the=20 recorded experiences of others, is a fool. The answers to many of your=20 questions could be found by studying the resources, to which you have=20 already been pointed, (one of which is that package of scripts). Do=20 so; if they raise further questions, then come back and ask. That is=20 what Michael means by `doing your homework'. If you insist on playing=20 the fool, by declining those resources to which you have been referred,=20 then don't be surprised to be treated as such. Show willing to do the=20 homework, then come back with informed questions, and you are more=20 likely to get an informed answer. Regards, Keith. |
From: <ch...@gm...> - 2008-01-25 00:46:45
|
Keith Marshall wrote: > >> therefore, an automated script that prepares everything for me is not >> what I want now. >> > > Really? Not even as a study resource? He who refuses to learn from the > recorded experiences of others, is a fool. The answers to many of your > questions could be found by studying the resources, to which you have > already been pointed, (one of which is that package of scripts). Do > so; if they raise further questions, then come back and ask. That is > what Michael means by `doing your homework'. If you insist on playing > the fool, by declining those resources to which you have been referred, > then don't be surprised to be treated as such. Show willing to do the > homework, then come back with informed questions, and you are more > likely to get an informed answer. > > Regards, > Keith. > > Well, Keith, your words are harsh to me. I'm not that kind of person(fool?) you think. I just mean I will not try those automated scripts right now; I do not mean [ I hate those scripts and will never have a glance at them ]. I can't afford to try those scripts right now. There are primarily two reasons: * First, I'm not very familiar with bash shell programming yet, not knowing a bash script debugger either, and I can't easily understand what those scripts will do. This is not a issue I can solve in several hours, instead, several days are required. * A successful run of the script cost my PC two hours(I can estimate the time since I had done the cross compiler building by hand), -- its the time of building just one cross tools chain, needless to say doing a Canadian cross. If the scripts fail for some reason(due to my fault or to the script being unperfect), I think it'll be even harder to find out the reason. More explicitly, I can not guarantee I can run those scripts successfully in one or two tries, and if they require more tries, the large amount of time spent is hard to accept. Imaging, if I rely totally on some offered scripts, and I later want to change some build options to tune the building result, I have to start over again, -- another two hours consumed. On the other hand, if I first try to do it step by step by hand, I can record every step(success or fail) with VMWare workstation's awesome snapshot feature. If something proves wrong later, I can go back to the snapshot point to check the reason; if I want to tune some options later, I can find a suitable correct snapshot point and start tuning it there. Automated scripts is fantastic tool for their authors or someone who knows them inside out. For "alien" users, they are still very useful if the "interface" is clear and known. However, still sorry for not adopting your scripts now. Finally, if I find it unsuitable or can't afford to accept someone's advice on the mailing list, should I ignore it or explain it with my reason? (--If you find it unsuitable to answer, keeping quite is OK for me.) |
From: Earnie B. <ea...@us...> - 2008-01-25 01:27:21
|
Quoting "Chen (?) Jun (?)" <ch...@gm...>: > Well, Keith, your words are harsh to me. I'm not that kind of > person(fool?) you think. I just mean I will not try those automated > scripts right now; I do not mean [ I hate those scripts and will never > have a glance at them ]. > It may be harsh be precious time has been spent by Keith in making the scripts so that your questions can be answered by the scripts themselves. > I can't afford to try those scripts right now. There are primarily two > reasons: > * First, I'm not very familiar with bash shell programming yet, not > knowing a bash script debugger either, and I can't easily understand > what those scripts will do. This is not a issue I can solve in several > hours, instead, several days are required. Not hard really. You're already using some shell obviously. Bash isn't much different than any of the other commands. > * A successful run of the script cost my PC two hours(I can estimate the > time since I had done the cross compiler building by hand), -- its the > time of building just one cross tools chain, needless to say doing a > Canadian cross. If the scripts fail for some reason(due to my fault or > to the script being unperfect), I think it'll be even harder to find out > the reason. More explicitly, I can not guarantee I can run those scripts > successfully in one or two tries, and if they require more tries, the > large amount of time spent is hard to accept. > And a waste of your time by hand as well as automated. How much more will be spent in trying to find the answers to questions already accomplished with the scripts? How much time has been wasted of others by you asking questions that have already been cared for by the script? > Imaging, if I rely totally on some offered scripts, and I later want to > change some build options to tune the building result, I have to start > over again, -- another two hours consumed. On the other hand, if I first > try to do it step by step by hand, I can record every step(success or > fail) with VMWare workstation's awesome snapshot feature. If something > proves wrong later, I can go back to the snapshot point to check the > reason; if I want to tune some options later, I can find a suitable > correct snapshot point and start tuning it there. > And you should be able to do the same by executing a script as well. Executing a script is no different than executing a compiler command. > Automated scripts is fantastic tool for their authors or someone who > knows them inside out. For "alien" users, they are still very useful if > the "interface" is clear and known. However, still sorry for not > adopting your scripts now. > It sounds as if you're already alien to cross compiling and the script tries to help those alien's by guiding them in the right direction. > Finally, if I find it unsuitable or can't afford to accept someone's > advice on the mailing list, should I ignore it or explain it with my > reason? (--If you find it unsuitable to answer, keeping quite is OK for me.) > Yes. Earnie |
From: <ch...@gm...> - 2008-01-28 05:15:56
|
Earnie Boyd wrote: > Quoting "Chen (陈) Jun (军)" <ch...@gm...>: > > >> Well, Keith, your words are harsh to me. I'm not that kind of >> person(fool?) you think. I just mean I will not try those automated >> scripts right now; I do not mean [ I hate those scripts and will never >> have a glance at them ]. >> > > It may be harsh be precious time has been spent by Keith in making the > scripts so that your questions can be answered by the scripts > themselves. > > >> I can't afford to try those scripts right now. There are primarily two >> reasons: >> * First, I'm not very familiar with bash shell programming yet, not >> knowing a bash script debugger either, and I can't easily understand >> what those scripts will do. This is not a issue I can solve in several >> hours, instead, several days are required. > > Not hard really. You're already using some shell obviously. Bash > isn't much different than any of the other commands. > > >> * A successful run of the script cost my PC two hours(I can estimate the >> time since I had done the cross compiler building by hand), -- its the >> time of building just one cross tools chain, needless to say doing a >> Canadian cross. If the scripts fail for some reason(due to my fault or >> to the script being unperfect), I think it'll be even harder to find out >> the reason. More explicitly, I can not guarantee I can run those scripts >> successfully in one or two tries, and if they require more tries, the >> large amount of time spent is hard to accept. >> >> > > And a waste of your time by hand as well as automated. How much more > will be spent in trying to find the answers to questions already > accomplished with the scripts? How much time has been wasted of others > by you asking questions that have already been cared for by the script? > > >> Imaging, if I rely totally on some offered scripts, and I later want to >> change some build options to tune the building result, I have to start >> over again, -- another two hours consumed. On the other hand, if I first >> try to do it step by step by hand, I can record every step(success or >> fail) with VMWare workstation's awesome snapshot feature. If something >> proves wrong later, I can go back to the snapshot point to check the >> reason; if I want to tune some options later, I can find a suitable >> correct snapshot point and start tuning it there. > > And you should be able to do the same by executing a script as well. > Executing a script is no different than executing a compiler command. > > >> Automated scripts is fantastic tool for their authors or someone who >> knows them inside out. For "alien" users, they are still very useful if >> the "interface" is clear and known. However, still sorry for not >> adopting your scripts now. >> > > It sounds as if you're already alien to cross compiling and the script > tries to help those alien's by guiding them in the right direction. > Don't know your meaning by saying "if you're already alien to cross compiling", -- perhaps my statement is as well vague to you. Ignore it then. > >> Finally, if I find it unsuitable or can't afford to accept someone's >> advice on the mailing list, should I ignore it or explain it with my >> reason? (--If you find it unsuitable to answer, keeping quiet is OK for me.) >> >> > > Yes. > > Earnie > Hi, Earnie. There is an old Chinese saying "Giving him fish is inferior to teaching him fishing." (受之以鱼,不若受之以渔) So, giving me a automated script is like giving me a fish, and what I have asked is asking how to fish. Yes, except getting a final answer, I'd like to know something inside. Keith and Michael wrote those script to help themselves and others to do their work, which is great. But note again, I did not ask a question like "what commands should be used to build gcc" but "what could have caused such error, and why it caused such error" --the latter cannot be answered by a script. A workable script shows the bright side of building gcc, but there is still dark side; knowing both sides makes a person more brilliant, that is, "learn from failure". On the other hand, since Keith and Michael volunteer to help others on this mailing list(respectable of course), they have to be ready when someone blames or refuses to use their scripts due to its not being absolutely perfect. Of course, a script cannot solve everyone's problem(which would otherwise be a myth), but if it can solve for quite a few among ours, their time spent is deserved, right? So, if somebody don't accept your advice in this or that reason for which you could not conceive, be lenient to him. Don't you think so? |