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 --------------------------------------------------------- |