From: Shao M. <sha...@gm...> - 2012-09-24 03:47:47
|
Thanks again. Here is my scenario: - Development system for building coLinux and coLinux kernel: Fedora 15 - GCC ver. 4.6.3 - MinGW GCC ver. 4.5.3 The 'make' process appears to wish to build particular versions of tools, but I don't quite understand why. Why is it that it cannot use whatever tools I have installed? After reading doc/building.txt, I still am not clear on why. I did download all of the particular versions via 'make download'. But when I run 'make', it fails to build the binutils-2.19.1 that was downloaded. There are a few errors[1], but "fixing" them would seem to be out-of-scope for coLinux. So again, can I just use the tools that I have? I tried './configure --gcc-guest-build', but that didn't seem to do the trick. Thanks for your time, once more. - Shao [1] --- ERROR LOG /usr/src/colinux-devel/log/build-colinux-25679.err: In file included from ../../binutils-2.19.1/libiberty/regex.c:638:0: ../../binutils-2.19.1/libiberty/regex.c: In function byte_re_match_2_internal: ../../binutils-2.19.1/libiberty/regex.c:7141:27: warning: variable sdummy set but not used [-Wunused-but-set-variable] ../../binutils-2.19.1/libiberty/regex.c:7140:22: warning: variable pdummy set but not used [-Wunused-but-set-variable] ../../binutils-2.19.1/libiberty/regex.c:7476:5: warning: jump skips variable initialization [-Wjump-misses-init] ../../binutils-2.19.1/libiberty/regex.c:5952:12: note: label restore_best_regs defined here ../../binutils-2.19.1/libiberty/regex.c:5913:16: note: same_str_p declared here ../../binutils-2.19.1/bfd/compress.c: In function 'bfd_uncompress_section_contents': ../../binutils-2.19.1/bfd/compress.c:54:45: error: parameter 'buffer' set but not used [-Werror=unused-but-set-parameter] ../../binutils-2.19.1/bfd/compress.c:54:68: error: parameter 'size' set but not used [-Werror=unused-but-set-parameter] cc1: all warnings being treated as errors make[5]: *** [compress.lo] Error 1 make[4]: *** [all-recursive] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all-bfd] Error 2 make[1]: *** [all] Error 2 make binutils failed make: *** [cross] Error 1 ________________________________________ From: yin sun [mailto:sun...@gm...] Sent: Sunday, September 23, 2012 22:54 To: Shao Miller Subject: Re: [coLinux-users] Porting a Kernel patches are what colinux releases. the build process will download the original linux kernel code from the kernel official site first. once you download the svn devel branch. ./configure make will take care all of these. this topic should be discussed on dev mailing list. On Sun, Sep 23, 2012 at 7:25 PM, Shao Miller <sha...@gm...> wrote: Thank you. I am trying your suggestion. So far, I have needed bison, patch, flex, texinfo, texinfo-tex, gettext. I will see how it all goes. Is there an official SVN for coLinux Linux source, rather than just patches/ ? - Shao ________________________________________ From: yin sun [mailto:sun...@gm...] Sent: Sunday, September 23, 2012 20:15 To: Shao Miller Cc: col...@li... Subject: Re: [coLinux-users] Porting a Kernel current colinux kernel is based on 2.6.33.7 not very different from 2.6.38.6 you can try to go through the colinux build process first. once you are familiar with it, you should know how to port a new kernel. On Sun, Sep 23, 2012 at 2:04 PM, Shao Miller <sha...@gm...> wrote: Good day, folks. If I was interested in compiling a Linux kernel for use with coLinux, how might I go about it? Are there instructions already documented? I have the Linux source and the coLinux source. I was planning on reviewing the items inside coLinux' patch/ directory, then porting those into a branch in my Linux git repository. Does that make the most sense? For the curious, I'm wanting to get Fedora 15's 2.6.38.6-rc1 kernel running under coLinux so I can port my installation away from VMware and to coLinux. Fedora 15 is "end-of-life," but oh well. Thank you for your time. - Shao ---------------------------------------------------------------------------- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ coLinux-users mailing list coL...@li... https://lists.sourceforge.net/lists/listinfo/colinux-users |
From: yin s. <sun...@gm...> - 2012-09-24 04:02:24
|
your error looks like a gcc problem. try use gcc 4.4 since we are building kernel program/device driver, the compiler version/flags is important. in this case, I think gcc 4.6 never been tested to work. On Sun, Sep 23, 2012 at 8:47 PM, Shao Miller <sha...@gm...> wrote: > Thanks again. > > Here is my scenario: > > - Development system for building coLinux and coLinux kernel: Fedora 15 > - GCC ver. 4.6.3 > - MinGW GCC ver. 4.5.3 > > The 'make' process appears to wish to build particular versions of tools, > but I don't quite understand why. Why is it that it cannot use whatever > tools I have installed? After reading doc/building.txt, I still am not > clear on why. > > I did download all of the particular versions via 'make download'. But > when > I run 'make', it fails to build the binutils-2.19.1 that was downloaded. > There are a few errors[1], but "fixing" them would seem to be out-of-scope > for coLinux. So again, can I just use the tools that I have? I tried > './configure --gcc-guest-build', but that didn't seem to do the trick. > > Thanks for your time, once more. > > - Shao > > [1] > > --- ERROR LOG /usr/src/colinux-devel/log/build-colinux-25679.err: > In file included from ../../binutils-2.19.1/libiberty/regex.c:638:0: > ../../binutils-2.19.1/libiberty/regex.c: In function > ‘byte_re_match_2_internal’: > ../../binutils-2.19.1/libiberty/regex.c:7141:27: warning: variable > ‘sdummy’ set but not used [-Wunused-but-set-variable] > ../../binutils-2.19.1/libiberty/regex.c:7140:22: warning: variable > ‘pdummy’ set but not used [-Wunused-but-set-variable] > ../../binutils-2.19.1/libiberty/regex.c:7476:5: warning: jump skips > variable initialization [-Wjump-misses-init] > ../../binutils-2.19.1/libiberty/regex.c:5952:12: note: label > ‘restore_best_regs’ defined here > ../../binutils-2.19.1/libiberty/regex.c:5913:16: note: ‘same_str_p’ > declared here > ../../binutils-2.19.1/bfd/compress.c: In function > 'bfd_uncompress_section_contents': > ../../binutils-2.19.1/bfd/compress.c:54:45: error: parameter 'buffer' set > but not used [-Werror=unused-but-set-parameter] > ../../binutils-2.19.1/bfd/compress.c:54:68: error: parameter 'size' set > but not used [-Werror=unused-but-set-parameter] > cc1: all warnings being treated as errors > make[5]: *** [compress.lo] Error 1 > make[4]: *** [all-recursive] Error 1 > make[3]: *** [all] Error 2 > make[2]: *** [all-bfd] Error 2 > make[1]: *** [all] Error 2 > make binutils failed > make: *** [cross] Error 1 > > ________________________________________ > From: yin sun [mailto:sun...@gm...] > Sent: Sunday, September 23, 2012 22:54 > To: Shao Miller > Subject: Re: [coLinux-users] Porting a Kernel > > patches are what colinux releases. the build process will download the > original linux kernel code from the kernel official site first. > once you download the svn devel branch. > ./configure > make > will take care all of these. this topic should be discussed on dev mailing > list. > On Sun, Sep 23, 2012 at 7:25 PM, Shao Miller <sha...@gm...> > wrote: > Thank you. > > I am trying your suggestion. So far, I have needed bison, patch, flex, > texinfo, texinfo-tex, gettext. I will see how it all goes. > > Is there an official SVN for coLinux Linux source, rather than just > patches/ > ? > > - Shao > > ________________________________________ > From: yin sun [mailto:sun...@gm...] > Sent: Sunday, September 23, 2012 20:15 > To: Shao Miller > Cc: col...@li... > Subject: Re: [coLinux-users] Porting a Kernel > > current colinux kernel is based on 2.6.33.7 not very different from > 2.6.38.6 > you can try to go through the colinux build process first. once you are > familiar with it, > you should know how to port a new kernel. > On Sun, Sep 23, 2012 at 2:04 PM, Shao Miller <sha...@gm...> > wrote: > Good day, folks. > > If I was interested in compiling a Linux kernel for use with coLinux, how > might I go about it? Are there instructions already documented? > > I have the Linux source and the coLinux source. I was planning on > reviewing > the items inside coLinux' patch/ directory, then porting those into a > branch > in my Linux git repository. Does that make the most sense? > > For the curious, I'm wanting to get Fedora 15's 2.6.38.6-rc1 kernel running > under coLinux so I can port my installation away from VMware and to > coLinux. > Fedora 15 is "end-of-life," but oh well. > > Thank you for your time. > > - Shao > > > > ---------------------------------------------------------------------------- > -- > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://ad.doubleclick.net/clk;258768047;13503038;j? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > coLinux-users mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-users > > > > |
From: yin s. <sun...@gm...> - 2012-09-24 04:17:04
|
and look at the error again, "error: parameter 'buffer' set but not used [-Werror=unused-but-set-parameter]" if you don't want to change gcc, maybe you can disable warning as error flag. and try again. On Sun, Sep 23, 2012 at 9:01 PM, yin sun <sun...@gm...> wrote: > your error looks like a gcc problem. try use gcc 4.4 > since we are building kernel program/device driver, the compiler > version/flags is important. > in this case, I think gcc 4.6 never been tested to work. > > > On Sun, Sep 23, 2012 at 8:47 PM, Shao Miller <sha...@gm...>wrote: > >> Thanks again. >> >> Here is my scenario: >> >> - Development system for building coLinux and coLinux kernel: Fedora 15 >> - GCC ver. 4.6.3 >> - MinGW GCC ver. 4.5.3 >> >> The 'make' process appears to wish to build particular versions of tools, >> but I don't quite understand why. Why is it that it cannot use whatever >> tools I have installed? After reading doc/building.txt, I still am not >> clear on why. >> >> I did download all of the particular versions via 'make download'. But >> when >> I run 'make', it fails to build the binutils-2.19.1 that was downloaded. >> There are a few errors[1], but "fixing" them would seem to be out-of-scope >> for coLinux. So again, can I just use the tools that I have? I tried >> './configure --gcc-guest-build', but that didn't seem to do the trick. >> >> Thanks for your time, once more. >> >> - Shao >> >> [1] >> >> --- ERROR LOG /usr/src/colinux-devel/log/build-colinux-25679.err: >> In file included from ../../binutils-2.19.1/libiberty/regex.c:638:0: >> ../../binutils-2.19.1/libiberty/regex.c: In function >> ‘byte_re_match_2_internal’: >> ../../binutils-2.19.1/libiberty/regex.c:7141:27: warning: variable >> ‘sdummy’ set but not used [-Wunused-but-set-variable] >> ../../binutils-2.19.1/libiberty/regex.c:7140:22: warning: variable >> ‘pdummy’ set but not used [-Wunused-but-set-variable] >> ../../binutils-2.19.1/libiberty/regex.c:7476:5: warning: jump skips >> variable initialization [-Wjump-misses-init] >> ../../binutils-2.19.1/libiberty/regex.c:5952:12: note: label >> ‘restore_best_regs’ defined here >> ../../binutils-2.19.1/libiberty/regex.c:5913:16: note: ‘same_str_p’ >> declared here >> ../../binutils-2.19.1/bfd/compress.c: In function >> 'bfd_uncompress_section_contents': >> ../../binutils-2.19.1/bfd/compress.c:54:45: error: parameter 'buffer' >> set >> but not used [-Werror=unused-but-set-parameter] >> ../../binutils-2.19.1/bfd/compress.c:54:68: error: parameter 'size' set >> but not used [-Werror=unused-but-set-parameter] >> cc1: all warnings being treated as errors >> make[5]: *** [compress.lo] Error 1 >> make[4]: *** [all-recursive] Error 1 >> make[3]: *** [all] Error 2 >> make[2]: *** [all-bfd] Error 2 >> make[1]: *** [all] Error 2 >> make binutils failed >> make: *** [cross] Error 1 >> >> ________________________________________ >> From: yin sun [mailto:sun...@gm...] >> Sent: Sunday, September 23, 2012 22:54 >> To: Shao Miller >> Subject: Re: [coLinux-users] Porting a Kernel >> >> patches are what colinux releases. the build process will download the >> original linux kernel code from the kernel official site first. >> once you download the svn devel branch. >> ./configure >> make >> will take care all of these. this topic should be discussed on dev mailing >> list. >> On Sun, Sep 23, 2012 at 7:25 PM, Shao Miller <sha...@gm...> >> wrote: >> Thank you. >> >> I am trying your suggestion. So far, I have needed bison, patch, flex, >> texinfo, texinfo-tex, gettext. I will see how it all goes. >> >> Is there an official SVN for coLinux Linux source, rather than just >> patches/ >> ? >> >> - Shao >> >> ________________________________________ >> From: yin sun [mailto:sun...@gm...] >> Sent: Sunday, September 23, 2012 20:15 >> To: Shao Miller >> Cc: col...@li... >> Subject: Re: [coLinux-users] Porting a Kernel >> >> current colinux kernel is based on 2.6.33.7 not very different from >> 2.6.38.6 >> you can try to go through the colinux build process first. once you are >> familiar with it, >> you should know how to port a new kernel. >> On Sun, Sep 23, 2012 at 2:04 PM, Shao Miller <sha...@gm...> >> wrote: >> Good day, folks. >> >> If I was interested in compiling a Linux kernel for use with coLinux, how >> might I go about it? Are there instructions already documented? >> >> I have the Linux source and the coLinux source. I was planning on >> reviewing >> the items inside coLinux' patch/ directory, then porting those into a >> branch >> in my Linux git repository. Does that make the most sense? >> >> For the curious, I'm wanting to get Fedora 15's 2.6.38.6-rc1 kernel >> running >> under coLinux so I can port my installation away from VMware and to >> coLinux. >> Fedora 15 is "end-of-life," but oh well. >> >> Thank you for your time. >> >> - Shao >> >> >> >> ---------------------------------------------------------------------------- >> -- >> Everyone hates slow websites. So do we. >> Make your web apps faster with AppDynamics >> Download AppDynamics Lite for free today: >> http://ad.doubleclick.net/clk;258768047;13503038;j? >> http://info.appdynamics.com/FreeJavaPerformanceDownload.html >> _______________________________________________ >> coLinux-users mailing list >> coL...@li... >> https://lists.sourceforge.net/lists/listinfo/colinux-users >> >> >> >> > |
From: Shao M. <sha...@gm...> - 2012-09-24 06:05:48
|
Yes, well... I've got the following notes[1], which have allowed me to compile the 2.6.33.7-co-0.7.10 kernel using the tools from Fedora 15. I haven't tested the kernel in coLinux yet. Right now I'm stuck trying to figure out why #include <FL/Fl.H> isn't working, when I certainly have /usr/include/FL/Fl.H. I suppose I don't really need to compile the rest of coLinux in order to test the kernel... Or maybe I do. - Shao [1] cd /usr/src/colinux-devel/colinux # Then edited ./configure so that: # # case $GCC_VERSION in # 4.5.*|4.3.*|4.2.*|4.1.*|4.0.*|3.4.*) ./configure make download # Then edited bin/build-common.sh so that: # # BINUTILS_VERSION="2.21" # GCC_VERSION="4.5.3" cd /usr/src/colinux-devel/mingw32 mkdir bin cd bin ln -s /usr/bin/i686-pc-mingw32-gcc i686-pc-mingw32-gcc ln -s /usr/bin/i686-pc-mingw32-ld i686-pc-mingw32-ld ln -s /usr/bin/i686-pc-mingw32-windres i686-pc-mingw32-windres ln -s /usr/bin/i686-pc-mingw32-strip i686-pc-mingw32-strip # Then edited /usr/src/colinux-devel/build/linux-2.6.33.7-source/arch/x86/vdso/Makefile so that: # # VDSO_LDFLAGS_vdso32.lds = -m32 -Wl,-soname=linux-gate.so.1 cd /usr/src/colinux-devel/colinux export CFLAGS=-Wno-unused-but-set-variable make ________________________________________ From: yin sun [mailto:sun...@gm...] Sent: Monday, September 24, 2012 00:17 To: Shao Miller Cc: col...@li... Subject: Re: [coLinux-users] Porting a Kernel and look at the error again, "error: parameter 'buffer' set but not used [-Werror=unused-but-set-parameter]" if you don't want to change gcc, maybe you can disable warning as error flag. and try again. On Sun, Sep 23, 2012 at 9:01 PM, yin sun <sun...@gm...> wrote: your error looks like a gcc problem. try use gcc 4.4 since we are building kernel program/device driver, the compiler version/flags is important. in this case, I think gcc 4.6 never been tested to work. On Sun, Sep 23, 2012 at 8:47 PM, Shao Miller <sha...@gm...> wrote: Thanks again. Here is my scenario: - Development system for building coLinux and coLinux kernel: Fedora 15 - GCC ver. 4.6.3 - MinGW GCC ver. 4.5.3 The 'make' process appears to wish to build particular versions of tools, but I don't quite understand why. Why is it that it cannot use whatever tools I have installed? After reading doc/building.txt, I still am not clear on why. I did download all of the particular versions via 'make download'. But when I run 'make', it fails to build the binutils-2.19.1 that was downloaded. There are a few errors[1], but "fixing" them would seem to be out-of-scope for coLinux. So again, can I just use the tools that I have? I tried './configure --gcc-guest-build', but that didn't seem to do the trick. Thanks for your time, once more. - Shao [1] --- ERROR LOG /usr/src/colinux-devel/log/build-colinux-25679.err: In file included from ../../binutils-2.19.1/libiberty/regex.c:638:0: ../../binutils-2.19.1/libiberty/regex.c: In function byte_re_match_2_internal: ../../binutils-2.19.1/libiberty/regex.c:7141:27: warning: variable sdummy set but not used [-Wunused-but-set-variable] ../../binutils-2.19.1/libiberty/regex.c:7140:22: warning: variable pdummy set but not used [-Wunused-but-set-variable] ../../binutils-2.19.1/libiberty/regex.c:7476:5: warning: jump skips variable initialization [-Wjump-misses-init] ../../binutils-2.19.1/libiberty/regex.c:5952:12: note: label restore_best_regs defined here ../../binutils-2.19.1/libiberty/regex.c:5913:16: note: same_str_p declared here ../../binutils-2.19.1/bfd/compress.c: In function 'bfd_uncompress_section_contents': ../../binutils-2.19.1/bfd/compress.c:54:45: error: parameter 'buffer' set but not used [-Werror=unused-but-set-parameter] ../../binutils-2.19.1/bfd/compress.c:54:68: error: parameter 'size' set but not used [-Werror=unused-but-set-parameter] cc1: all warnings being treated as errors make[5]: *** [compress.lo] Error 1 make[4]: *** [all-recursive] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all-bfd] Error 2 make[1]: *** [all] Error 2 make binutils failed make: *** [cross] Error 1 ________________________________________ From: yin sun [mailto:sun...@gm...] Sent: Sunday, September 23, 2012 22:54 To: Shao Miller Subject: Re: [coLinux-users] Porting a Kernel patches are what colinux releases. the build process will download the original linux kernel code from the kernel official site first. once you download the svn devel branch. ./configure make will take care all of these. this topic should be discussed on dev mailing list. On Sun, Sep 23, 2012 at 7:25 PM, Shao Miller <sha...@gm...> wrote: Thank you. I am trying your suggestion. So far, I have needed bison, patch, flex, texinfo, texinfo-tex, gettext. I will see how it all goes. Is there an official SVN for coLinux Linux source, rather than just patches/ ? - Shao ________________________________________ From: yin sun [mailto:sun...@gm...] Sent: Sunday, September 23, 2012 20:15 To: Shao Miller Cc: col...@li... Subject: Re: [coLinux-users] Porting a Kernel current colinux kernel is based on 2.6.33.7 not very different from 2.6.38.6 you can try to go through the colinux build process first. once you are familiar with it, you should know how to port a new kernel. On Sun, Sep 23, 2012 at 2:04 PM, Shao Miller <sha...@gm...> wrote: Good day, folks. If I was interested in compiling a Linux kernel for use with coLinux, how might I go about it? Are there instructions already documented? I have the Linux source and the coLinux source. I was planning on reviewing the items inside coLinux' patch/ directory, then porting those into a branch in my Linux git repository. Does that make the most sense? For the curious, I'm wanting to get Fedora 15's 2.6.38.6-rc1 kernel running under coLinux so I can port my installation away from VMware and to coLinux. Fedora 15 is "end-of-life," but oh well. Thank you for your time. - Shao ---------------------------------------------------------------------------- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ coLinux-users mailing list coL...@li... https://lists.sourceforge.net/lists/listinfo/colinux-users |
From: yin s. <sun...@gm...> - 2012-09-24 16:08:21
|
no, you can just download a precompiled 0.7.10 colinux gz file from Henry's page then replace the vmlinux to test. to compile fltk console, you need the mingw-gcc cross compilation tool set. this is to compile a exe for windows. also, very likely you may need to compile a new device driver for windows with the new kernel later on. On Sun, Sep 23, 2012 at 11:05 PM, Shao Miller <sha...@gm...> wrote: > Yes, well... > > I've got the following notes[1], which have allowed me to compile the > 2.6.33.7-co-0.7.10 kernel using the tools from Fedora 15. I haven't tested > the kernel in coLinux yet. > > Right now I'm stuck trying to figure out why #include <FL/Fl.H> isn't > working, when I certainly have /usr/include/FL/Fl.H. I suppose I don't > really need to compile the rest of coLinux in order to test the kernel... > Or maybe I do. > > - Shao > > [1] > cd /usr/src/colinux-devel/colinux > > # Then edited ./configure so that: > # > # case $GCC_VERSION in > # 4.5.*|4.3.*|4.2.*|4.1.*|4.0.*|3.4.*) > > ./configure > make download > > # Then edited bin/build-common.sh so that: > # > # BINUTILS_VERSION="2.21" > # GCC_VERSION="4.5.3" > > cd /usr/src/colinux-devel/mingw32 > mkdir bin > cd bin > ln -s /usr/bin/i686-pc-mingw32-gcc i686-pc-mingw32-gcc > ln -s /usr/bin/i686-pc-mingw32-ld i686-pc-mingw32-ld > ln -s /usr/bin/i686-pc-mingw32-windres i686-pc-mingw32-windres > ln -s /usr/bin/i686-pc-mingw32-strip i686-pc-mingw32-strip > > # Then edited > /usr/src/colinux-devel/build/linux-2.6.33.7-source/arch/x86/vdso/Makefile > so > that: > # > # VDSO_LDFLAGS_vdso32.lds = -m32 -Wl,-soname=linux-gate.so.1 > > cd /usr/src/colinux-devel/colinux > export CFLAGS=-Wno-unused-but-set-variable > make > > ________________________________________ > From: yin sun [mailto:sun...@gm...] > Sent: Monday, September 24, 2012 00:17 > To: Shao Miller > Cc: col...@li... > Subject: Re: [coLinux-users] Porting a Kernel > > and look at the error again, "error: parameter 'buffer' set but not used > [-Werror=unused-but-set-parameter]" > if you don't want to change gcc, maybe you can disable warning as error > flag. and try again. > On Sun, Sep 23, 2012 at 9:01 PM, yin sun <sun...@gm...> wrote: > your error looks like a gcc problem. try use gcc 4.4 > since we are building kernel program/device driver, the compiler > version/flags is important. > in this case, I think gcc 4.6 never been tested to work. > > On Sun, Sep 23, 2012 at 8:47 PM, Shao Miller <sha...@gm...> > wrote: > Thanks again. > > Here is my scenario: > > - Development system for building coLinux and coLinux kernel: Fedora 15 > - GCC ver. 4.6.3 > - MinGW GCC ver. 4.5.3 > > The 'make' process appears to wish to build particular versions of tools, > but I don't quite understand why. Why is it that it cannot use whatever > tools I have installed? After reading doc/building.txt, I still am not > clear on why. > > I did download all of the particular versions via 'make download'. But > when > I run 'make', it fails to build the binutils-2.19.1 that was downloaded. > There are a few errors[1], but "fixing" them would seem to be out-of-scope > for coLinux. So again, can I just use the tools that I have? I tried > './configure --gcc-guest-build', but that didn't seem to do the trick. > > Thanks for your time, once more. > > - Shao > > [1] > > --- ERROR LOG /usr/src/colinux-devel/log/build-colinux-25679.err: > In file included from ../../binutils-2.19.1/libiberty/regex.c:638:0: > ../../binutils-2.19.1/libiberty/regex.c: In function > ‘byte_re_match_2_internal’: > ../../binutils-2.19.1/libiberty/regex.c:7141:27: warning: variable > ‘sdummy’ set but not used [-Wunused-but-set-variable] > ../../binutils-2.19.1/libiberty/regex.c:7140:22: warning: variable > ‘pdummy’ set but not used [-Wunused-but-set-variable] > ../../binutils-2.19.1/libiberty/regex.c:7476:5: warning: jump skips > variable initialization [-Wjump-misses-init] > ../../binutils-2.19.1/libiberty/regex.c:5952:12: note: label > ‘restore_best_regs’ defined here > ../../binutils-2.19.1/libiberty/regex.c:5913:16: note: ‘same_str_p’ > declared here > ../../binutils-2.19.1/bfd/compress.c: In function > 'bfd_uncompress_section_contents': > ../../binutils-2.19.1/bfd/compress.c:54:45: error: parameter 'buffer' set > but not used [-Werror=unused-but-set-parameter] > ../../binutils-2.19.1/bfd/compress.c:54:68: error: parameter 'size' set > but not used [-Werror=unused-but-set-parameter] > cc1: all warnings being treated as errors > make[5]: *** [compress.lo] Error 1 > make[4]: *** [all-recursive] Error 1 > make[3]: *** [all] Error 2 > make[2]: *** [all-bfd] Error 2 > make[1]: *** [all] Error 2 > make binutils failed > make: *** [cross] Error 1 > > ________________________________________ > From: yin sun [mailto:sun...@gm...] > Sent: Sunday, September 23, 2012 22:54 > To: Shao Miller > Subject: Re: [coLinux-users] Porting a Kernel > > patches are what colinux releases. the build process will download the > original linux kernel code from the kernel official site first. > once you download the svn devel branch. > ./configure > make > will take care all of these. this topic should be discussed on dev mailing > list. > On Sun, Sep 23, 2012 at 7:25 PM, Shao Miller <sha...@gm...> > wrote: > Thank you. > > I am trying your suggestion. So far, I have needed bison, patch, flex, > texinfo, texinfo-tex, gettext. I will see how it all goes. > > Is there an official SVN for coLinux Linux source, rather than just > patches/ > ? > > - Shao > > ________________________________________ > From: yin sun [mailto:sun...@gm...] > Sent: Sunday, September 23, 2012 20:15 > To: Shao Miller > Cc: col...@li... > Subject: Re: [coLinux-users] Porting a Kernel > > current colinux kernel is based on 2.6.33.7 not very different from > 2.6.38.6 > you can try to go through the colinux build process first. once you are > familiar with it, > you should know how to port a new kernel. > On Sun, Sep 23, 2012 at 2:04 PM, Shao Miller <sha...@gm...> > wrote: > Good day, folks. > > If I was interested in compiling a Linux kernel for use with coLinux, how > might I go about it? Are there instructions already documented? > > I have the Linux source and the coLinux source. I was planning on > reviewing > the items inside coLinux' patch/ directory, then porting those into a > branch > in my Linux git repository. Does that make the most sense? > > For the curious, I'm wanting to get Fedora 15's 2.6.38.6-rc1 kernel running > under coLinux so I can port my installation away from VMware and to > coLinux. > Fedora 15 is "end-of-life," but oh well. > > Thank you for your time. > > - Shao > > > > ---------------------------------------------------------------------------- > -- > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://ad.doubleclick.net/clk;258768047;13503038;j? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > coLinux-users mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-users > > > > > > |
From: Shao M. <sha...@gm...> - 2012-09-24 17:08:58
|
Right. In my notes, you can see that I spoofed the build system into using the MinGW that I already have. Although 'make download' downloaded a particular version of FLTK, apparently it didn't build it prior to the 'make colinux' business. I don't quite know why, as I suspect 'make colinux' is looking for <FL/Fl.H> wherever the downloaded package is supposed to be built. I had to laugh, though... When testing the kernel with coLinux 0.7.8.1525, I realized that the Linux installation was x86_64, so I don't think that'll work! I got some lines from the kernel when it tried to load the init program about a runaway loop for modprobing a particular binfmt, which I assume must've been because the init program was x86_64. - Shao ________________________________________ From: yin sun [mailto:sun...@gm...] Sent: Monday, September 24, 2012 12:08 To: Shao Miller Cc: col...@li... Subject: Re: [coLinux-users] Porting a Kernel no, you can just download a precompiled 0.7.10 colinux gz file from Henry's page then replace the vmlinux to test. to compile fltk console, you need the mingw-gcc cross compilation tool set. this is to compile a exe for windows. also, very likely you may need to compile a new device driver for windows with the new kernel later on. On Sun, Sep 23, 2012 at 11:05 PM, Shao Miller <sha...@gm...> wrote: Yes, well... I've got the following notes[1], which have allowed me to compile the 2.6.33.7-co-0.7.10 kernel using the tools from Fedora 15. I haven't tested the kernel in coLinux yet. Right now I'm stuck trying to figure out why #include <FL/Fl.H> isn't working, when I certainly have /usr/include/FL/Fl.H. I suppose I don't really need to compile the rest of coLinux in order to test the kernel... Or maybe I do. - Shao [1] cd /usr/src/colinux-devel/colinux # Then edited ./configure so that: # # case $GCC_VERSION in # 4.5.*|4.3.*|4.2.*|4.1.*|4.0.*|3.4.*) ./configure make download # Then edited bin/build-common.sh so that: # # BINUTILS_VERSION="2.21" # GCC_VERSION="4.5.3" cd /usr/src/colinux-devel/mingw32 mkdir bin cd bin ln -s /usr/bin/i686-pc-mingw32-gcc i686-pc-mingw32-gcc ln -s /usr/bin/i686-pc-mingw32-ld i686-pc-mingw32-ld ln -s /usr/bin/i686-pc-mingw32-windres i686-pc-mingw32-windres ln -s /usr/bin/i686-pc-mingw32-strip i686-pc-mingw32-strip # Then edited /usr/src/colinux-devel/build/linux-2.6.33.7-source/arch/x86/vdso/Makefile so that: # # VDSO_LDFLAGS_vdso32.lds = -m32 -Wl,-soname=linux-gate.so.1 cd /usr/src/colinux-devel/colinux export CFLAGS=-Wno-unused-but-set-variable make ________________________________________ From: yin sun [mailto:sun...@gm...] Sent: Monday, September 24, 2012 00:17 To: Shao Miller Cc: col...@li... Subject: Re: [coLinux-users] Porting a Kernel and look at the error again, "error: parameter 'buffer' set but not used [-Werror=unused-but-set-parameter]" if you don't want to change gcc, maybe you can disable warning as error flag. and try again. On Sun, Sep 23, 2012 at 9:01 PM, yin sun <sun...@gm...> wrote: your error looks like a gcc problem. try use gcc 4.4 since we are building kernel program/device driver, the compiler version/flags is important. in this case, I think gcc 4.6 never been tested to work. On Sun, Sep 23, 2012 at 8:47 PM, Shao Miller <sha...@gm...> wrote: Thanks again. Here is my scenario: - Development system for building coLinux and coLinux kernel: Fedora 15 - GCC ver. 4.6.3 - MinGW GCC ver. 4.5.3 The 'make' process appears to wish to build particular versions of tools, but I don't quite understand why. Why is it that it cannot use whatever tools I have installed? After reading doc/building.txt, I still am not clear on why. I did download all of the particular versions via 'make download'. But when I run 'make', it fails to build the binutils-2.19.1 that was downloaded. There are a few errors[1], but "fixing" them would seem to be out-of-scope for coLinux. So again, can I just use the tools that I have? I tried './configure --gcc-guest-build', but that didn't seem to do the trick. Thanks for your time, once more. - Shao [1] --- ERROR LOG /usr/src/colinux-devel/log/build-colinux-25679.err: In file included from ../../binutils-2.19.1/libiberty/regex.c:638:0: ../../binutils-2.19.1/libiberty/regex.c: In function byte_re_match_2_internal: ../../binutils-2.19.1/libiberty/regex.c:7141:27: warning: variable sdummy set but not used [-Wunused-but-set-variable] ../../binutils-2.19.1/libiberty/regex.c:7140:22: warning: variable pdummy set but not used [-Wunused-but-set-variable] ../../binutils-2.19.1/libiberty/regex.c:7476:5: warning: jump skips variable initialization [-Wjump-misses-init] ../../binutils-2.19.1/libiberty/regex.c:5952:12: note: label restore_best_regs defined here ../../binutils-2.19.1/libiberty/regex.c:5913:16: note: same_str_p declared here ../../binutils-2.19.1/bfd/compress.c: In function 'bfd_uncompress_section_contents': ../../binutils-2.19.1/bfd/compress.c:54:45: error: parameter 'buffer' set but not used [-Werror=unused-but-set-parameter] ../../binutils-2.19.1/bfd/compress.c:54:68: error: parameter 'size' set but not used [-Werror=unused-but-set-parameter] cc1: all warnings being treated as errors make[5]: *** [compress.lo] Error 1 make[4]: *** [all-recursive] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all-bfd] Error 2 make[1]: *** [all] Error 2 make binutils failed make: *** [cross] Error 1 ________________________________________ From: yin sun [mailto:sun...@gm...] Sent: Sunday, September 23, 2012 22:54 To: Shao Miller Subject: Re: [coLinux-users] Porting a Kernel patches are what colinux releases. the build process will download the original linux kernel code from the kernel official site first. once you download the svn devel branch. ./configure make will take care all of these. this topic should be discussed on dev mailing list. On Sun, Sep 23, 2012 at 7:25 PM, Shao Miller <sha...@gm...> wrote: Thank you. I am trying your suggestion. So far, I have needed bison, patch, flex, texinfo, texinfo-tex, gettext. I will see how it all goes. Is there an official SVN for coLinux Linux source, rather than just patches/ ? - Shao ________________________________________ From: yin sun [mailto:sun...@gm...] Sent: Sunday, September 23, 2012 20:15 To: Shao Miller Cc: col...@li... Subject: Re: [coLinux-users] Porting a Kernel current colinux kernel is based on 2.6.33.7 not very different from 2.6.38.6 you can try to go through the colinux build process first. once you are familiar with it, you should know how to port a new kernel. On Sun, Sep 23, 2012 at 2:04 PM, Shao Miller <sha...@gm...> wrote: Good day, folks. If I was interested in compiling a Linux kernel for use with coLinux, how might I go about it? Are there instructions already documented? I have the Linux source and the coLinux source. I was planning on reviewing the items inside coLinux' patch/ directory, then porting those into a branch in my Linux git repository. Does that make the most sense? For the curious, I'm wanting to get Fedora 15's 2.6.38.6-rc1 kernel running under coLinux so I can port my installation away from VMware and to coLinux. Fedora 15 is "end-of-life," but oh well. Thank you for your time. - Shao ---------------------------------------------------------------------------- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ coLinux-users mailing list coL...@li... https://lists.sourceforge.net/lists/listinfo/colinux-users |
From: H. N. <hen...@ar...> - 2012-09-24 18:18:15
|
You need the FLTK version that was supported by coLinux, and for the coLinux under Linux you need a patched FLTK version (with a additional hook function, see http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/patch/fltk-1.1.10-linux-patch.diff). For simple build of coLinux it was better to have our one FLTK, separated from system, which was known and configured with minimalistic features with only used functions and only static lib, and compatible to the source code. Often under /usr/local/... a newer FLTK version was installed, and that mostly not works. FLTK has changed arguments for function between major versions. So, if you have a running Cross compiler, just build the FLTK lib with coLinux build process, and than build the daemons and FLTK-console. To build FLTK you needs to run "make libs" or bin/build-colinux-libs.sh Henry ----- Original Nachricht ---- Von: Shao Miller <sha...@gm...> An: 'yin sun' <sun...@gm...> Datum: 24.09.2012 19:08 Betreff: Re: [coLinux-devel] [coLinux-users] Porting a Kernel > Right. In my notes, you can see that I spoofed the build system into using > the MinGW that I already have. > > Although 'make download' downloaded a particular version of FLTK, > apparently > it didn't build it prior to the 'make colinux' business. I don't quite > know > why, as I suspect 'make colinux' is looking for <FL/Fl.H> wherever the > downloaded package is supposed to be built. > > I had to laugh, though... When testing the kernel with coLinux 0.7.8.1525, > I realized that the Linux installation was x86_64, so I don't think that'll > work! I got some lines from the kernel when it tried to load the init > program about a runaway loop for modprobing a particular binfmt, which I > assume must've been because the init program was x86_64. > > - Shao > > ________________________________________ > From: yin sun [mailto:sun...@gm...] > Sent: Monday, September 24, 2012 12:08 > To: Shao Miller > Cc: col...@li... > Subject: Re: [coLinux-users] Porting a Kernel > > no, you can just download a precompiled 0.7.10 colinux gz file from Henry's > page then replace the vmlinux to test. > to compile fltk console, you need the mingw-gcc cross compilation tool set. > this is to compile a exe for windows. > also, very likely you may need to compile a new device driver for windows > with the new kernel later on. > On Sun, Sep 23, 2012 at 11:05 PM, Shao Miller <sha...@gm...> > wrote: > Yes, well... > > I've got the following notes[1], which have allowed me to compile the > 2.6.33.7-co-0.7.10 kernel using the tools from Fedora 15. I haven't tested > the kernel in coLinux yet. > > Right now I'm stuck trying to figure out why #include <FL/Fl.H> isn't > working, when I certainly have /usr/include/FL/Fl.H. I suppose I don't > really need to compile the rest of coLinux in order to test the kernel... > Or maybe I do. > > - Shao > > [1] > cd /usr/src/colinux-devel/colinux > > # Then edited ./configure so that: > # > # case $GCC_VERSION in > # 4.5.*|4.3.*|4.2.*|4.1.*|4.0.*|3.4.*) > > ./configure > make download > > # Then edited bin/build-common.sh so that: > # > # BINUTILS_VERSION="2.21" > # GCC_VERSION="4.5.3" > > cd /usr/src/colinux-devel/mingw32 > mkdir bin > cd bin > ln -s /usr/bin/i686-pc-mingw32-gcc i686-pc-mingw32-gcc > ln -s /usr/bin/i686-pc-mingw32-ld i686-pc-mingw32-ld > ln -s /usr/bin/i686-pc-mingw32-windres i686-pc-mingw32-windres > ln -s /usr/bin/i686-pc-mingw32-strip i686-pc-mingw32-strip > > # Then edited > /usr/src/colinux-devel/build/linux-2.6.33.7-source/arch/x86/vdso/Makefile > so > that: > # > # VDSO_LDFLAGS_vdso32.lds = -m32 -Wl,-soname=linux-gate.so.1 > > cd /usr/src/colinux-devel/colinux > export CFLAGS=-Wno-unused-but-set-variable > make > > ________________________________________ > From: yin sun [mailto:sun...@gm...] > Sent: Monday, September 24, 2012 00:17 > To: Shao Miller > Cc: col...@li... > Subject: Re: [coLinux-users] Porting a Kernel > > and look at the error again, "error: parameter 'buffer' set but not used > [-Werror=unused-but-set-parameter]" > if you don't want to change gcc, maybe you can disable warning as error > flag. and try again. > On Sun, Sep 23, 2012 at 9:01 PM, yin sun <sun...@gm...> wrote: > your error looks like a gcc problem. try use gcc 4.4 > since we are building kernel program/device driver, the compiler > version/flags is important. > in this case, I think gcc 4.6 never been tested to work. > > On Sun, Sep 23, 2012 at 8:47 PM, Shao Miller <sha...@gm...> wrote: > Thanks again. > > Here is my scenario: > > - Development system for building coLinux and coLinux kernel: Fedora 15 > - GCC ver. 4.6.3 > - MinGW GCC ver. 4.5.3 > > The 'make' process appears to wish to build particular versions of tools, > but I don't quite understand why. Why is it that it cannot use whatever > tools I have installed? After reading doc/building.txt, I still am not > clear on why. > > I did download all of the particular versions via 'make download'. But > when > I run 'make', it fails to build the binutils-2.19.1 that was downloaded. > There are a few errors[1], but "fixing" them would seem to be out-of-scope > for coLinux. So again, can I just use the tools that I have? I tried > './configure --gcc-guest-build', but that didn't seem to do the trick. > > Thanks for your time, once more. > > - Shao > > [1] > > --- ERROR LOG /usr/src/colinux-devel/log/build-colinux-25679.err: > In file included from ../../binutils-2.19.1/libiberty/regex.c:638:0: > ../../binutils-2.19.1/libiberty/regex.c: In function > byte_re_match_2_internal: > ../../binutils-2.19.1/libiberty/regex.c:7141:27: warning: variable > sdummy set but not used [-Wunused-but-set-variable] > ../../binutils-2.19.1/libiberty/regex.c:7140:22: warning: variable > pdummy set but not used [-Wunused-but-set-variable] > ../../binutils-2.19.1/libiberty/regex.c:7476:5: warning: jump skips > variable initialization [-Wjump-misses-init] > ../../binutils-2.19.1/libiberty/regex.c:5952:12: note: label > restore_best_regs defined here > ../../binutils-2.19.1/libiberty/regex.c:5913:16: note: same_str_p > declared here > ../../binutils-2.19.1/bfd/compress.c: In function > 'bfd_uncompress_section_contents': > ../../binutils-2.19.1/bfd/compress.c:54:45: error: parameter 'buffer' set > but not used [-Werror=unused-but-set-parameter] > ../../binutils-2.19.1/bfd/compress.c:54:68: error: parameter 'size' set > but not used [-Werror=unused-but-set-parameter] > cc1: all warnings being treated as errors > make[5]: *** [compress.lo] Error 1 > make[4]: *** [all-recursive] Error 1 > make[3]: *** [all] Error 2 > make[2]: *** [all-bfd] Error 2 > make[1]: *** [all] Error 2 > make binutils failed > make: *** [cross] Error 1 > > ________________________________________ > From: yin sun [mailto:sun...@gm...] > Sent: Sunday, September 23, 2012 22:54 > To: Shao Miller > Subject: Re: [coLinux-users] Porting a Kernel > > patches are what colinux releases. the build process will download the > original linux kernel code from the kernel official site first. > once you download the svn devel branch. > ./configure > make > will take care all of these. this topic should be discussed on dev mailing > list. > On Sun, Sep 23, 2012 at 7:25 PM, Shao Miller <sha...@gm...> wrote: > Thank you. > > I am trying your suggestion. So far, I have needed bison, patch, flex, > texinfo, texinfo-tex, gettext. I will see how it all goes. > > Is there an official SVN for coLinux Linux source, rather than just > patches/ > ? > > - Shao > > ________________________________________ > From: yin sun [mailto:sun...@gm...] > Sent: Sunday, September 23, 2012 20:15 > To: Shao Miller > Cc: col...@li... > Subject: Re: [coLinux-users] Porting a Kernel > > current colinux kernel is based on 2.6.33.7 not very different from > 2.6.38.6 > you can try to go through the colinux build process first. once you are > familiar with it, > you should know how to port a new kernel. > On Sun, Sep 23, 2012 at 2:04 PM, Shao Miller <sha...@gm...> wrote: > Good day, folks. > > If I was interested in compiling a Linux kernel for use with coLinux, how > might I go about it? Are there instructions already documented? > > I have the Linux source and the coLinux source. I was planning on > reviewing > the items inside coLinux' patch/ directory, then porting those into a > branch > in my Linux git repository. Does that make the most sense? > > For the curious, I'm wanting to get Fedora 15's 2.6.38.6-rc1 kernel running > under coLinux so I can port my installation away from VMware and to > coLinux. > Fedora 15 is "end-of-life," but oh well. > > Thank you for your time. > > - Shao > > > ---------------------------------------------------------------------------- > > -- > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://ad.doubleclick.net/clk;258768047;13503038;j? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > coLinux-users mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-users > > > > > > > > ---------------------------------------------------------------------------- > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > coLinux-devel mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-devel > -- Gruss Henry --------------------------------------------------------- |
From: H. N. <hen...@ar...> - 2012-09-25 11:32:46
|
Forgotten to say: I used "quilt" for handling kernel patches. Henry ----- Original Nachricht ---- Von: "H. Nestler" <hen...@ar...> An: sha...@gm... Datum: 24.09.2012 20:18 Betreff: Re: [coLinux-devel] [coLinux-users] Porting a Kernel > You need the FLTK version that was supported by coLinux, and for the coLinux > under Linux you need a patched FLTK version (with a additional hook > function, see > http://colinux.svn.sourceforge.net/viewvc/colinux/branches/devel/patch/fltk- > 1.1.10-linux-patch.diff). For simple build of coLinux it was better to have > our one FLTK, separated from system, which was known and configured with > minimalistic features with only used functions and only static lib, and > compatible to the source code. Often under /usr/local/... a newer FLTK > version was installed, and that mostly not works. FLTK has changed arguments > for function between major versions. > > So, if you have a running Cross compiler, just build the FLTK lib with > coLinux build process, and than build the daemons and FLTK-console. > > To build FLTK you needs to run "make libs" or bin/build-colinux-libs.sh > > Henry > > ----- Original Nachricht ---- > Von: Shao Miller <sha...@gm...> > An: 'yin sun' <sun...@gm...> > Datum: 24.09.2012 19:08 > Betreff: Re: [coLinux-devel] [coLinux-users] Porting a Kernel > > > Right. In my notes, you can see that I spoofed the build system into > using > > the MinGW that I already have. > > > > Although 'make download' downloaded a particular version of FLTK, > > apparently > > it didn't build it prior to the 'make colinux' business. I don't quite > > know > > why, as I suspect 'make colinux' is looking for <FL/Fl.H> wherever the > > downloaded package is supposed to be built. > > > > I had to laugh, though... When testing the kernel with coLinux > 0.7.8.1525, > > I realized that the Linux installation was x86_64, so I don't think > that'll > > work! I got some lines from the kernel when it tried to load the init > > program about a runaway loop for modprobing a particular binfmt, which I > > assume must've been because the init program was x86_64. > > > > - Shao > > > > ________________________________________ > > From: yin sun [mailto:sun...@gm...] > > Sent: Monday, September 24, 2012 12:08 > > To: Shao Miller > > Cc: col...@li... > > Subject: Re: [coLinux-users] Porting a Kernel > > > > no, you can just download a precompiled 0.7.10 colinux gz file from > Henry's > > page then replace the vmlinux to test. > > to compile fltk console, you need the mingw-gcc cross compilation tool > set. > > this is to compile a exe for windows. > > also, very likely you may need to compile a new device driver for windows > > with the new kernel later on. > > On Sun, Sep 23, 2012 at 11:05 PM, Shao Miller <sha...@gm...> > > wrote: > > Yes, well... > > > > I've got the following notes[1], which have allowed me to compile the > > 2.6.33.7-co-0.7.10 kernel using the tools from Fedora 15. I haven't > tested > > the kernel in coLinux yet. > > > > Right now I'm stuck trying to figure out why #include <FL/Fl.H> isn't > > working, when I certainly have /usr/include/FL/Fl.H. I suppose I don't > > really need to compile the rest of coLinux in order to test the kernel... > > Or maybe I do. > > > > - Shao > > > > [1] > > cd /usr/src/colinux-devel/colinux > > > > # Then edited ./configure so that: > > # > > # case $GCC_VERSION in > > # 4.5.*|4.3.*|4.2.*|4.1.*|4.0.*|3.4.*) > > > > ./configure > > make download > > > > # Then edited bin/build-common.sh so that: > > # > > # BINUTILS_VERSION="2.21" > > # GCC_VERSION="4.5.3" > > > > cd /usr/src/colinux-devel/mingw32 > > mkdir bin > > cd bin > > ln -s /usr/bin/i686-pc-mingw32-gcc i686-pc-mingw32-gcc > > ln -s /usr/bin/i686-pc-mingw32-ld i686-pc-mingw32-ld > > ln -s /usr/bin/i686-pc-mingw32-windres i686-pc-mingw32-windres > > ln -s /usr/bin/i686-pc-mingw32-strip i686-pc-mingw32-strip > > > > # Then edited > > /usr/src/colinux-devel/build/linux-2.6.33.7-source/arch/x86/vdso/Makefile > > so > > that: > > # > > # VDSO_LDFLAGS_vdso32.lds = -m32 -Wl,-soname=linux-gate.so.1 > > > > cd /usr/src/colinux-devel/colinux > > export CFLAGS=-Wno-unused-but-set-variable > > make > > > > ________________________________________ > > From: yin sun [mailto:sun...@gm...] > > Sent: Monday, September 24, 2012 00:17 > > To: Shao Miller > > Cc: col...@li... > > Subject: Re: [coLinux-users] Porting a Kernel > > > > and look at the error again, "error: parameter 'buffer' set but not used > > [-Werror=unused-but-set-parameter]" > > if you don't want to change gcc, maybe you can disable warning as error > > flag. and try again. > > On Sun, Sep 23, 2012 at 9:01 PM, yin sun <sun...@gm...> wrote: > > your error looks like a gcc problem. try use gcc 4.4 > > since we are building kernel program/device driver, the compiler > > version/flags is important. > > in this case, I think gcc 4.6 never been tested to work. > > > > On Sun, Sep 23, 2012 at 8:47 PM, Shao Miller <sha...@gm...> > wrote: > > Thanks again. > > > > Here is my scenario: > > > > - Development system for building coLinux and coLinux kernel: Fedora 15 > > - GCC ver. 4.6.3 > > - MinGW GCC ver. 4.5.3 > > > > The 'make' process appears to wish to build particular versions of tools, > > but I don't quite understand why. Why is it that it cannot use whatever > > tools I have installed? After reading doc/building.txt, I still am not > > clear on why. > > > > I did download all of the particular versions via 'make download'. But > > when > > I run 'make', it fails to build the binutils-2.19.1 that was downloaded. > > There are a few errors[1], but "fixing" them would seem to be > out-of-scope > > for coLinux. So again, can I just use the tools that I have? I tried > > './configure --gcc-guest-build', but that didn't seem to do the trick. > > > > Thanks for your time, once more. > > > > - Shao > > > > [1] > > > > --- ERROR LOG /usr/src/colinux-devel/log/build-colinux-25679.err: > > In file included from ../../binutils-2.19.1/libiberty/regex.c:638:0: > > ../../binutils-2.19.1/libiberty/regex.c: In function > > byte_re_match_2_internal: > > ../../binutils-2.19.1/libiberty/regex.c:7141:27: warning: variable > > sdummy set but not used [-Wunused-but-set-variable] > > ../../binutils-2.19.1/libiberty/regex.c:7140:22: warning: variable > > pdummy set but not used [-Wunused-but-set-variable] > > ../../binutils-2.19.1/libiberty/regex.c:7476:5: warning: jump skips > > variable initialization [-Wjump-misses-init] > > ../../binutils-2.19.1/libiberty/regex.c:5952:12: note: label > > restore_best_regs defined here > > ../../binutils-2.19.1/libiberty/regex.c:5913:16: note: same_str_p > > declared here > > ../../binutils-2.19.1/bfd/compress.c: In function > > 'bfd_uncompress_section_contents': > > ../../binutils-2.19.1/bfd/compress.c:54:45: error: parameter 'buffer' > set > > but not used [-Werror=unused-but-set-parameter] > > ../../binutils-2.19.1/bfd/compress.c:54:68: error: parameter 'size' set > > but not used [-Werror=unused-but-set-parameter] > > cc1: all warnings being treated as errors > > make[5]: *** [compress.lo] Error 1 > > make[4]: *** [all-recursive] Error 1 > > make[3]: *** [all] Error 2 > > make[2]: *** [all-bfd] Error 2 > > make[1]: *** [all] Error 2 > > make binutils failed > > make: *** [cross] Error 1 > > > > ________________________________________ > > From: yin sun [mailto:sun...@gm...] > > Sent: Sunday, September 23, 2012 22:54 > > To: Shao Miller > > Subject: Re: [coLinux-users] Porting a Kernel > > > > patches are what colinux releases. the build process will download the > > original linux kernel code from the kernel official site first. > > once you download the svn devel branch. > > ./configure > > make > > will take care all of these. this topic should be discussed on dev > mailing > > list. > > On Sun, Sep 23, 2012 at 7:25 PM, Shao Miller <sha...@gm...> > wrote: > > Thank you. > > > > I am trying your suggestion. So far, I have needed bison, patch, flex, > > texinfo, texinfo-tex, gettext. I will see how it all goes. > > > > Is there an official SVN for coLinux Linux source, rather than just > > patches/ > > ? > > > > - Shao > > > > ________________________________________ > > From: yin sun [mailto:sun...@gm...] > > Sent: Sunday, September 23, 2012 20:15 > > To: Shao Miller > > Cc: col...@li... > > Subject: Re: [coLinux-users] Porting a Kernel > > > > current colinux kernel is based on 2.6.33.7 not very different from > > 2.6.38.6 > > you can try to go through the colinux build process first. once you are > > familiar with it, > > you should know how to port a new kernel. > > On Sun, Sep 23, 2012 at 2:04 PM, Shao Miller <sha...@gm...> > wrote: > > Good day, folks. > > > > If I was interested in compiling a Linux kernel for use with coLinux, how > > might I go about it? Are there instructions already documented? > > > > I have the Linux source and the coLinux source. I was planning on > > reviewing > > the items inside coLinux' patch/ directory, then porting those into a > > branch > > in my Linux git repository. Does that make the most sense? > > > > For the curious, I'm wanting to get Fedora 15's 2.6.38.6-rc1 kernel > running > > under coLinux so I can port my installation away from VMware and to > > coLinux. > > Fedora 15 is "end-of-life," but oh well. > > > > Thank you for your time. > > > > - Shao > > > > > > > ---------------------------------------------------------------------------- > > > > > -- > > Everyone hates slow websites. So do we. > > Make your web apps faster with AppDynamics > > Download AppDynamics Lite for free today: > > http://ad.doubleclick.net/clk;258768047;13503038;j? > > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > > _______________________________________________ > > coLinux-users mailing list > > coL...@li... > > https://lists.sourceforge.net/lists/listinfo/colinux-users > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------------- > > > -- > > Live Security Virtual Conference > > Exclusive live event will cover all the ways today's security and > > threat landscape has changed and how IT managers can respond. Discussions > > > will include endpoint security, mobile security and the latest in malware > > > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > > _______________________________________________ > > coLinux-devel mailing list > > coL...@li... > > https://lists.sourceforge.net/lists/listinfo/colinux-devel > > -- Gruss Henry --------------------------------------------------------- |
From: Shao M. <sha...@gm...> - 2012-09-26 08:15:18
|
Did you ever find a strategy in regards to using i686-w64-mingw32 and the ntddk.h -> wdm.h #inclusion problem[1]? I'm now using a 32-bit Fedora 17 instead of a 64-bit Fedora 15 and trying 'make colinux'. - Shao [1] http://sourceforge.net/mailarchive/forum.php?thread_name=AANLkTikR1c9vBySfL7 CNu4JXmtVsLNGgThmmbuhhKYbv%40mail.gmail.com&forum_name=mingw-w64-public |
From: Shao M. <sha...@gm...> - 2012-09-27 23:47:38
|
What is the Linux kernel upstream position on any coLinux changes getting merged, or has there been any discussion about this? I'm sure some of the #ifndef CONFIG_COOPERATIVE changes might be considered to spaghettify the code, but have alternative strategies been pondered or proposed? - Shao |
From: yin s. <sun...@gm...> - 2012-09-28 00:42:24
|
I had thought about this. the two approaches we can learn from is lguest and paravirt. basically colinux could be another architecture in kernel tree on host and guest implement something similar to paravirt-ops. On Thu, Sep 27, 2012 at 4:47 PM, Shao Miller <sha...@gm...> wrote: > What is the Linux kernel upstream position on any coLinux changes getting > merged, or has there been any discussion about this? > > I'm sure some of the #ifndef CONFIG_COOPERATIVE changes might be considered > to spaghettify the code, but have alternative strategies been pondered or > proposed? > > - Shao > > > > ------------------------------------------------------------------------------ > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://ad.doubleclick.net/clk;258768047;13503038;j? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > coLinux-devel mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-devel > |
From: Shao M. <sha...@gm...> - 2013-04-03 03:58:45
|
Since the patches are falling further behind modern Linux, it seems to be getting harder and harder to run a modern (think "non-end-of-life") Linux distribution in coLinux. Is the paravirt path one which coLinux could really take? Are there obstacles besides development time, such as design decisions needing to be revisited? - Shao Miller ________________________________________ From: yin sun [mailto:sun...@gm...] Sent: Thursday, September 27, 2012 20:42 To: Shao Miller Cc: col...@li... Subject: Re: [coLinux-devel] Porting a Kernel I had thought about this. the two approaches we can learn from is lguest and paravirt. basically colinux could be another architecture in kernel tree on host and guest implement something similar to paravirt-ops. On Thu, Sep 27, 2012 at 4:47 PM, Shao Miller <sha...@gm...> wrote: What is the Linux kernel upstream position on any coLinux changes getting merged, or has there been any discussion about this? I'm sure some of the #ifndef CONFIG_COOPERATIVE changes might be considered to spaghettify the code, but have alternative strategies been pondered or proposed? - Shao ---------------------------------------------------------------------------- -- Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://ad.doubleclick.net/clk;258768047;13503038;j? http://info.appdynamics.com/FreeJavaPerformanceDownload.html _______________________________________________ coLinux-devel mailing list coL...@li... https://lists.sourceforge.net/lists/listinfo/colinux-devel |
From: yin s. <sun...@gm...> - 2013-04-03 04:20:12
|
not really, as long as windows 32bit dosn't change, colinux patch is not that far off. On Tue, Apr 2, 2013 at 8:58 PM, Shao Miller <sha...@gm...> wrote: > Since the patches are falling further behind modern Linux, it seems to be > getting harder and harder to run a modern (think "non-end-of-life") Linux > distribution in coLinux. > > Is the paravirt path one which coLinux could really take? Are there > obstacles besides development time, such as design decisions needing to be > revisited? > > - Shao Miller > > ________________________________________ > From: yin sun [mailto:sun...@gm...] > Sent: Thursday, September 27, 2012 20:42 > To: Shao Miller > Cc: col...@li... > Subject: Re: [coLinux-devel] Porting a Kernel > > I had thought about this. the two approaches we can learn from is lguest > and > paravirt. > basically colinux could be another architecture in kernel tree on host and > guest implement something similar to paravirt-ops. > On Thu, Sep 27, 2012 at 4:47 PM, Shao Miller <sha...@gm...> > wrote: > What is the Linux kernel upstream position on any coLinux changes getting > merged, or has there been any discussion about this? > > I'm sure some of the #ifndef CONFIG_COOPERATIVE changes might be considered > to spaghettify the code, but have alternative strategies been pondered or > proposed? > > - Shao > > > > ---------------------------------------------------------------------------- > -- > Everyone hates slow websites. So do we. > Make your web apps faster with AppDynamics > Download AppDynamics Lite for free today: > http://ad.doubleclick.net/clk;258768047;13503038;j? > http://info.appdynamics.com/FreeJavaPerformanceDownload.html > _______________________________________________ > coLinux-devel mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-devel > > > > > ------------------------------------------------------------------------------ > Minimize network downtime and maximize team effectiveness. > Reduce network management and security costs.Learn how to hire > the most talented Cisco Certified professionals. Visit the > Employer Resources Portal > http://www.cisco.com/web/learning/employer_resources/index.html > _______________________________________________ > coLinux-devel mailing list > coL...@li... > https://lists.sourceforge.net/lists/listinfo/colinux-devel > |
From: George P B. <geo...@gm...> - 2013-04-19 20:37:47
|
Shao, If I remember correctly the biggest obstacle to coLinux using more modern kernel was a change in how the Memory was dealt with. Around the version that coLinux got stuck at there was a change to NUMA memory access which made Linux better for larger memory configurations, but created enough difference that it was problematic to bring coLinux patches in line with the kernel AND still map between the coLinux driver and Windows Memory... It's been a really long time so my memory could be off... George On 4/2/2013 10:58 PM, Shao Miller wrote: > Since the patches are falling further behind modern Linux, it seems to be > getting harder and harder to run a modern (think "non-end-of-life") Linux > distribution in coLinux. > > Is the paravirt path one which coLinux could really take? Are there > obstacles besides development time, such as design decisions needing to be > revisited? |