colinux-devel

[coLinux-devel] memory setting with the next release

[Dan A. <da...@co...>]

Hello,

The last version in snapshots (which I added today) contains the 
reimplemented allocation method. I'm delaying the release since one 
issue needs to be resolved with this allocation method.

There is a shortcoming with Windows' cache memory policy. On my 
256MB setup, Windows sometimes refuses to release cache pages that 
could accommodate memory for coLinux. This means that with large memory 
settings, it is hard to tell whether the next coLinux boot would 
succeed. On that machine, the 128MB setting reaches that limit, and 
I am forced to bring it down to somewhat 110MB for it to boot.

Another issue is that I don't have machines with more than 256MB of RAM 
to test this version with. I'd like to know about the typical behavior 
on setups with bigger amounts of RAM.

So, try the snapshot with various RAM settings and send results.

-- 
Dan Aloni
da...@co...

[coLinux-devel] building 20040313/cannot build

[Sean B. <sea...@so...>]

Hi,

Attempting to build the 20040313 snapshot.

Using tool chain created from cobuild.sh the make fails with:

i686-pc-cygwin-gcc colinux/common/common.o
colinux/os/current/user/user.o
colinux/os/current/user/conet-daemon/main.o colinux
/os/current/user/conet-daemon/tap-win32.o colinux/user/user.a -o
colinux/os/current/user/conet-daemon/colinux-net-daemon.exe 
-L/usr/src/colinux/cygwin/target/i686-pc-cygwin/lib/w32api -luser32
-lgdi32 -lkernel32 -lmxml
i686-pc-cygwin-gcc -mpush-args -mno-accumulate-outgoing-args
-Wno-trigraphs -O2 -fno-strict-aliasing -Wall  -D__KERNEL__ -DCO
_KERNEL -DCO_HOST_KERNEL -DWINVER=0x05000 -I. -I./../../linux/include
-I/usr/src/colinux/cygwin/target/i686-pc-cygwin/include
/w32api -c colinux/kernel/monitor.c -o colinux/kernel/monitor.o
colinux/kernel/monitor.c: In function `colinux_init':
colinux/kernel/monitor.c:140: error: `CO_VPTR_PSEUDO_RAM_PAGE_TABLES'
undeclared (first use in this function)
colinux/kernel/monitor.c:140: error: (Each undeclared identifier is
reported only once
colinux/kernel/monitor.c:140: error: for each function it appears in.)
colinux/kernel/monitor.c:153: error:
`CO_VPTR_PHYSICAL_TO_PSEUDO_PFN_MAP' undeclared (first use in this
function)
colinux/kernel/monitor.c:165: error: `CO_VPTR_SELF_MAP' undeclared
(first use in this function)
colinux/kernel/monitor.c:191: error: `CO_VPTR_PASSAGE_PAGE' undeclared
(first use in this function)
colinux/kernel/monitor.c: In function `co_monitor_iteration':
colinux/kernel/monitor.c:408: error: structure has no member named
`linuxvm_state'
colinux/kernel/monitor.c:409: error: structure has no member named
`linuxvm_state'
colinux/kernel/monitor.c:410: error: structure has no member named
`linuxvm_state'
colinux/kernel/monitor.c:411: error: structure has no member named
`linuxvm_state'
colinux/kernel/monitor.c:412: error: structure has no member named
`linuxvm_state'
colinux/kernel/monitor.c:413: error: structure has no member named
`linuxvm_state'
colinux/kernel/monitor.c:414: error: structure has no member named
`linuxvm_state'
colinux/kernel/monitor.c: In function `alloc_pseudo_physical_memory':
colinux/kernel/monitor.c:585: error: `CO_VPTR_PSEUDO_RAM_PAGE_TABLES'
undeclared (first use in this function)
colinux/kernel/monitor.c: In function `co_monitor_create':
colinux/kernel/monitor.c:704: error: `CO_VPTR_PASSAGE_PAGE' undeclared
(first use in this function)
colinux/kernel/monitor.c: At top level:
colinux/kernel/monitor.c:100: warning: `colinux_dump_page_at_address'
defined but not used
make: *** [colinux/kernel/monitor.o] Error 1

I have also created gentoo ebuilds for the toolchain as well as colinux.
Using these builds the make fails with:

i686-pc-cygwin-gcc
-Wl,--base-file,colinux/os/current/build/driver.base.tmp \
-Wl,--entry,_DriverEntry@8 \
-nostartfiles -nostdlib \
        -o junk.tmp colinux/os/current/build/driver.o -lntoskrnl -lhal
-lgcc
colinux/os/current/build/driver.o(.text+0x43f2):alloc.c: undefined
reference to `__imp__MmAllocatePagesForMdl@28'
colinux/os/current/build/driver.o(.text+0x44b9):alloc.c: undefined
reference to `__imp__MmMapIoSpace@16'
collect2: ld returned 1 exit status
make: *** [colinux/os/current/build/driver.base.tmp] Error 1

With the environment created with cobuild.sh and my ebuilds I have been
able to build all snapshots and releases up until this snapshot. Any
ideas of what is happening?
I think it may be possible that the tool chain needs to be updated in
some way. I also think it may be to do with the linker but I have no
idea and as far as I can tell it is finding the w32api libs ie
notoskrnl.

Re: [coLinux-devel] building 20040313/cannot build

[Thomas F. <tf...@no...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi,

I don't have system access now to check this out in detail, but it looks
like a problem in colinux. Also the name for the symbols looks like the
parts of the program where Dan is currently working.

Greetings, Thomas


> Hi,
>
> Attempting to build the 20040313 snapshot.
>
> Using tool chain created from cobuild.sh the make fails with:
>
> i686-pc-cygwin-gcc colinux/common/common.o
> colinux/os/current/user/user.o
> colinux/os/current/user/conet-daemon/main.o colinux
> /os/current/user/conet-daemon/tap-win32.o colinux/user/user.a -o
> colinux/os/current/user/conet-daemon/colinux-net-daemon.exe
> -L/usr/src/colinux/cygwin/target/i686-pc-cygwin/lib/w32api -luser32
> -lgdi32 -lkernel32 -lmxml
> i686-pc-cygwin-gcc -mpush-args -mno-accumulate-outgoing-args
> -Wno-trigraphs -O2 -fno-strict-aliasing -Wall  -D__KERNEL__ -DCO
> _KERNEL -DCO_HOST_KERNEL -DWINVER=0x05000 -I. -I./../../linux/include
> -I/usr/src/colinux/cygwin/target/i686-pc-cygwin/include
> /w32api -c colinux/kernel/monitor.c -o colinux/kernel/monitor.o
> colinux/kernel/monitor.c: In function `colinux_init':
> colinux/kernel/monitor.c:140: error: `CO_VPTR_PSEUDO_RAM_PAGE_TABLES'
> undeclared (first use in this function)
> colinux/kernel/monitor.c:140: error: (Each undeclared identifier is
> reported only once
> colinux/kernel/monitor.c:140: error: for each function it appears in.)
> colinux/kernel/monitor.c:153: error:
> `CO_VPTR_PHYSICAL_TO_PSEUDO_PFN_MAP' undeclared (first use in this
> function)
> colinux/kernel/monitor.c:165: error: `CO_VPTR_SELF_MAP' undeclared
> (first use in this function)
> colinux/kernel/monitor.c:191: error: `CO_VPTR_PASSAGE_PAGE' undeclared
> (first use in this function)
> colinux/kernel/monitor.c: In function `co_monitor_iteration':
> colinux/kernel/monitor.c:408: error: structure has no member named
> `linuxvm_state'
> colinux/kernel/monitor.c:409: error: structure has no member named
> `linuxvm_state'
> colinux/kernel/monitor.c:410: error: structure has no member named
> `linuxvm_state'
> colinux/kernel/monitor.c:411: error: structure has no member named
> `linuxvm_state'
> colinux/kernel/monitor.c:412: error: structure has no member named
> `linuxvm_state'
> colinux/kernel/monitor.c:413: error: structure has no member named
> `linuxvm_state'
> colinux/kernel/monitor.c:414: error: structure has no member named
> `linuxvm_state'
> colinux/kernel/monitor.c: In function `alloc_pseudo_physical_memory':
> colinux/kernel/monitor.c:585: error: `CO_VPTR_PSEUDO_RAM_PAGE_TABLES'
> undeclared (first use in this function)
> colinux/kernel/monitor.c: In function `co_monitor_create':
> colinux/kernel/monitor.c:704: error: `CO_VPTR_PASSAGE_PAGE' undeclared
> (first use in this function)
> colinux/kernel/monitor.c: At top level:
> colinux/kernel/monitor.c:100: warning: `colinux_dump_page_at_address'
> defined but not used
> make: *** [colinux/kernel/monitor.o] Error 1
>
> I have also created gentoo ebuilds for the toolchain as well as colinux.
> Using these builds the make fails with:
>
> i686-pc-cygwin-gcc
> -Wl,--base-file,colinux/os/current/build/driver.base.tmp \
> -Wl,--entry,_DriverEntry@8 \
> -nostartfiles -nostdlib \
>         -o junk.tmp colinux/os/current/build/driver.o -lntoskrnl -lhal
> -lgcc
> colinux/os/current/build/driver.o(.text+0x43f2):alloc.c: undefined
> reference to `__imp__MmAllocatePagesForMdl@28'
> colinux/os/current/build/driver.o(.text+0x44b9):alloc.c: undefined
> reference to `__imp__MmMapIoSpace@16'
> collect2: ld returned 1 exit status
> make: *** [colinux/os/current/build/driver.base.tmp] Error 1
>
> With the environment created with cobuild.sh and my ebuilds I have been
> able to build all snapshots and releases up until this snapshot. Any
> ideas of what is happening?
> I think it may be possible that the tool chain needs to be updated in
> some way. I also think it may be to do with the linker but I have no
> idea and as far as I can tell it is finding the w32api libs ie
> notoskrnl.
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> coLinux-devel mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-devel
>


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAVENFnwJBIFTVIqwRAvrLAJwOefATrqqjNDf3gjShy760OvOyWQCffsF3
Q791vzal7UhDyLpkSYDAW0A=
=wRCj
-----END PGP SIGNATURE-----

RE: [coLinux-devel] building 20040313/cannot build

[Sean B. <sea...@so...>]

Hello,

Thank you very much for that information. While I am at it,
thanks for cobuild.sh too :)

Cheers,

Sean.

> -----Original Message-----
> From: col...@li... 
> [mailto:col...@li...] On Behalf 
> Of Thomas Fritzsche
> Sent: Sunday, March 14, 2004 11:35 AM
> To: col...@li...
> Subject: Re: [coLinux-devel] building 20040313/cannot build
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> I don't have system access now to check this out in detail, 
> but it looks like a problem in colinux. Also the name for the 
> symbols looks like the parts of the program where Dan is 
> currently working.
> 
> Greetings, Thomas
> 
> 
> > Hi,
> >
> > Attempting to build the 20040313 snapshot.
> >
> > Using tool chain created from cobuild.sh the make fails with:
> >
> > i686-pc-cygwin-gcc colinux/common/common.o 
> > colinux/os/current/user/user.o 
> > colinux/os/current/user/conet-daemon/main.o colinux 
> > /os/current/user/conet-daemon/tap-win32.o colinux/user/user.a -o 
> > colinux/os/current/user/conet-daemon/colinux-net-daemon.exe
> > -L/usr/src/colinux/cygwin/target/i686-pc-cygwin/lib/w32api -luser32 
> > -lgdi32 -lkernel32 -lmxml i686-pc-cygwin-gcc -mpush-args 
> > -mno-accumulate-outgoing-args -Wno-trigraphs -O2 
> -fno-strict-aliasing 
> > -Wall  -D__KERNEL__ -DCO _KERNEL -DCO_HOST_KERNEL 
> -DWINVER=0x05000 -I. 
> > -I./../../linux/include 
> > -I/usr/src/colinux/cygwin/target/i686-pc-cygwin/include
> > /w32api -c colinux/kernel/monitor.c -o colinux/kernel/monitor.o
> > colinux/kernel/monitor.c: In function `colinux_init':
> > colinux/kernel/monitor.c:140: error: 
> `CO_VPTR_PSEUDO_RAM_PAGE_TABLES' 
> > undeclared (first use in this function)
> > colinux/kernel/monitor.c:140: error: (Each undeclared identifier is 
> > reported only once
> > colinux/kernel/monitor.c:140: error: for each function it 
> appears in.)
> > colinux/kernel/monitor.c:153: error: 
> > `CO_VPTR_PHYSICAL_TO_PSEUDO_PFN_MAP' undeclared (first use in this
> > function)
> > colinux/kernel/monitor.c:165: error: `CO_VPTR_SELF_MAP' undeclared 
> > (first use in this function)
> > colinux/kernel/monitor.c:191: error: `CO_VPTR_PASSAGE_PAGE' 
> undeclared 
> > (first use in this function)
> > colinux/kernel/monitor.c: In function `co_monitor_iteration':
> > colinux/kernel/monitor.c:408: error: structure has no member named 
> > `linuxvm_state'
> > colinux/kernel/monitor.c:409: error: structure has no member named 
> > `linuxvm_state'
> > colinux/kernel/monitor.c:410: error: structure has no member named 
> > `linuxvm_state'
> > colinux/kernel/monitor.c:411: error: structure has no member named 
> > `linuxvm_state'
> > colinux/kernel/monitor.c:412: error: structure has no member named 
> > `linuxvm_state'
> > colinux/kernel/monitor.c:413: error: structure has no member named 
> > `linuxvm_state'
> > colinux/kernel/monitor.c:414: error: structure has no member named 
> > `linuxvm_state'
> > colinux/kernel/monitor.c: In function 
> `alloc_pseudo_physical_memory':
> > colinux/kernel/monitor.c:585: error: 
> `CO_VPTR_PSEUDO_RAM_PAGE_TABLES' 
> > undeclared (first use in this function)
> > colinux/kernel/monitor.c: In function `co_monitor_create':
> > colinux/kernel/monitor.c:704: error: `CO_VPTR_PASSAGE_PAGE' 
> undeclared 
> > (first use in this function)
> > colinux/kernel/monitor.c: At top level:
> > colinux/kernel/monitor.c:100: warning: 
> `colinux_dump_page_at_address' 
> > defined but not used
> > make: *** [colinux/kernel/monitor.o] Error 1
> >
> > I have also created gentoo ebuilds for the toolchain as well as 
> > colinux. Using these builds the make fails with:
> >
> > i686-pc-cygwin-gcc 
> > -Wl,--base-file,colinux/os/current/build/driver.base.tmp \ 
> > -Wl,--entry,_DriverEntry@8 \ -nostartfiles -nostdlib \
> >         -o junk.tmp colinux/os/current/build/driver.o 
> -lntoskrnl -lhal
> > -lgcc
> > colinux/os/current/build/driver.o(.text+0x43f2):alloc.c: undefined
> > reference to `__imp__MmAllocatePagesForMdl@28'
> > colinux/os/current/build/driver.o(.text+0x44b9):alloc.c: undefined
> > reference to `__imp__MmMapIoSpace@16'
> > collect2: ld returned 1 exit status
> > make: *** [colinux/os/current/build/driver.base.tmp] Error 1
> >
> > With the environment created with cobuild.sh and my ebuilds I have 
> > been able to build all snapshots and releases up until this 
> snapshot. 
> > Any ideas of what is happening? I think it may be possible that the 
> > tool chain needs to be updated in some way. I also think it 
> may be to 
> > do with the linker but I have no idea and as far as I can 
> tell it is 
> > finding the w32api libs ie notoskrnl.
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President 
> and CEO of 
> > GenToo technologies. Learn everything from fundamentals to system 
> > 
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > _______________________________________________
> > coLinux-devel mailing list coL...@li...
> > https://lists.sourceforge.net/lists/listinfo/colinux-devel
> >
> 
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (GNU/Linux)
> 
> iD8DBQFAVENFnwJBIFTVIqwRAvrLAJwOefATrqqjNDf3gjShy760OvOyWQCffsF3
> Q791vzal7UhDyLpkSYDAW0A=
> =wRCj
> -----END PGP SIGNATURE-----
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President 
> and CEO of GenToo technologies. Learn everything from 
> fundamentals to system 
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> coLinux-devel mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-devel
> 

[coLinux-devel] Re: building 20040313/cannot build

[Dan A. <da...@co...>]

On Sun, Mar 14, 2004 at 06:31:33AM -0000, Sean Brook wrote:
> Hi,
> 
> Attempting to build the 20040313 snapshot.

It looks like you forgot to apply the new version of linux patch.

Plus, you need to recompile a patched version of w32api from 
sources, with fixed declarations for the two newly imported 
functions (look in ntoskrnl.def).
 
-- 
Dan Aloni
da...@co...

Re: [coLinux-devel] Re: building 20040313/cannot build

[Sean B. <sea...@so...>]

On Sunday 14 March 2004 16:57, Dan Aloni wrote:
> On Sun, Mar 14, 2004 at 06:31:33AM -0000, Sean Brook wrote:
> > Hi,
> >
> > Attempting to build the 20040313 snapshot.
>
> It looks like you forgot to apply the new version of linux patch.
Yes I forgot to apply the new version of the patch to the kernel
tree I use with cobuld.sh My gentoo ebuilds automatically patch
a vanilla source tarball which is completely separate from the
tree I use with cobuild.sh

>
> Plus, you need to recompile a patched version of w32api from
> sources, with fixed declarations for the two newly imported
> functions (look in ntoskrnl.def).
Great stuff. Thanks for the pointer. I made a new patch and it
compiled no problems. I made a new w32api-2.4.patch and
attached it to this mail.

Any advice on where to put the winpcap dev kit so I can
build conet-bridged-daemon?

Cheers,

Sean.

Re: [coLinux-devel] Re: building 20040313/cannot build

[Alejandro R. S. <as...@MI...>]

I've been working on this on and off, will get to it more once my laptop
gets back from Dell.

My build env has it i686-pc-cygwin/include, folded in with everything
else there. It's really a hack. What I'd like to see is it in
i686-pc-cygwin/include/wpcap or the like, I just don't have the make/gcc
foo to get that added to the include path. Alternativly, and the option
I'm leaning more towards now, is to patch the pcap include files so they
know they're in wpcap/, and deal appropriatly.

Things to note: the wpcap sdk looks like it was meant for windows, the
zip file has case issues in three files if I recall correctly. Also,
there's a types file that redefines some types (bittypes.h), which
should be replaced with a symlink to the cygwin stdint.h file.

-Alejandro

On Sun, 2004-03-14 at 06:09, Sean Brook wrote:
> On Sunday 14 March 2004 16:57, Dan Aloni wrote:
> > On Sun, Mar 14, 2004 at 06:31:33AM -0000, Sean Brook wrote:
> > > Hi,
> > >
> > > Attempting to build the 20040313 snapshot.
> >
> > It looks like you forgot to apply the new version of linux patch.
> Yes I forgot to apply the new version of the patch to the kernel
> tree I use with cobuld.sh My gentoo ebuilds automatically patch
> a vanilla source tarball which is completely separate from the
> tree I use with cobuild.sh
> 
> >
> > Plus, you need to recompile a patched version of w32api from
> > sources, with fixed declarations for the two newly imported
> > functions (look in ntoskrnl.def).
> Great stuff. Thanks for the pointer. I made a new patch and it
> compiled no problems. I made a new w32api-2.4.patch and
> attached it to this mail.
> 
> Any advice on where to put the winpcap dev kit so I can
> build conet-bridged-daemon?
> 
> Cheers,
> 
> Sean.

Re: [coLinux-devel] Re: building 20040313/cannot build

[Dan A. <da...@co...>]

On Sun, Mar 14, 2004 at 11:09:19AM +0000, Sean Brook wrote:
> On Sunday 14 March 2004 16:57, Dan Aloni wrote:
> > On Sun, Mar 14, 2004 at 06:31:33AM -0000, Sean Brook wrote:
> > > Hi,
> > >
> > > Attempting to build the 20040313 snapshot.
> >
> > It looks like you forgot to apply the new version of linux patch.
> Yes I forgot to apply the new version of the patch to the kernel
> tree I use with cobuld.sh My gentoo ebuilds automatically patch
> a vanilla source tarball which is completely separate from the
> tree I use with cobuild.sh
> 
> >
> > Plus, you need to recompile a patched version of w32api from
> > sources, with fixed declarations for the two newly imported
> > functions (look in ntoskrnl.def).
> Great stuff. Thanks for the pointer. I made a new patch and it
> compiled no problems. I made a new w32api-2.4.patch and
> attached it to this mail.

Cool, I was about to produce the same patch. I forwarded this to the 
author of w32api.

> Any advice on where to put the winpcap dev kit so I can
> build conet-bridged-daemon?

The files should be put in your $PREFIX/i686-pc-cygwin/lib and 
$PREFIX/i686-pc-cygwin/include directories.

-- 
Dan Aloni
da...@co...

Re: [coLinux-devel] Re: building 20040313/cannot build

[Sean B. <sea...@so...>]

> > Any advice on where to put the winpcap dev kit so I can
> > build conet-bridged-daemon?
>
> The files should be put in your $PREFIX/i686-pc-cygwin/lib and
> $PREFIX/i686-pc-cygwin/include directories.
Yes I presumed as much but the last time I looked there were name
collisions with headers and definitions. I want to know how you did
it.

Re: [coLinux-devel] Re: building 20040313/cannot build

[Thomas F. <tf...@no...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Dan,

could you please post this w32api-2.4.patch to the list (or wiki or in the
next release).

Thx,
 Thomas

>> > Plus, you need to recompile a patched version of w32api from
>> > sources, with fixed declarations for the two newly imported
>> > functions (look in ntoskrnl.def).
>> Great stuff. Thanks for the pointer. I made a new patch and it
>> compiled no problems. I made a new w32api-2.4.patch and
>> attached it to this mail.
>
> Cool, I was about to produce the same patch. I forwarded this to the
> author of w32api.
>


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAVXZxnwJBIFTVIqwRAoRBAJ99B1QkN/grMDukO29KyPL994Zp1QCdE/Iv
3fUerevZg0304E1Zhl7TSLw=
=ldJM
-----END PGP SIGNATURE-----

[coLinux-devel] Getting started building coLinux.

[Clemmitt M. S. <sig...@bl...>]

Hi all,

I've read the building and cygwin-cross-build files in the source
tarball's doc directory in preparation for trying out a build.  But
I have some *really* dumb questions, if anyone would be willing to
answer them:

1.) I couldn't find this in the building file but, if I understand 
correctly, the build system for both the coLinux kernel (vmlinux) and
the OS daemons and support code is i686-pc-linux.  IOW, you build
everything on a running Linux system, not under Windows.  Is this
correct?

2.) Is coLinux self-hosting, that is, can I build coLinux on a
running (and stable) coLinux system?

3.) Is it dumb to ask if it's possible to use MinGW rather than
Cygwin to do builds?  I know about using Cygwin and MinGW on Windows
as a shell and build environment, but I don't have any experience
using them as a build tool platform under Linux.  I do at least see
that w32api from MinGW is being used....

If I have time to work on building, I'll add the info I learn along
the way to the Wiki.  TIA.

					Clemmitt Sigler

Re: [coLinux-devel] Getting started building coLinux.

[Dmitriy K. <dm...@ka...>]

Welcome, Clemmitt.

You wrote 16 Mar 2004 ., 3:32:32:
CMS> 1.) I couldn't find this in the building file but, if I understand
CMS> correctly, the build system for both the coLinux kernel (vmlinux) an=
d
CMS> the OS daemons and support code is i686-pc-linux.  IOW, you build
As I understood, OS daemons/support code are built using
i686-pc-cygwin
CMS> everything on a running Linux system, not under Windows.  Is this
CMS> correct?
no

CMS> 2.) Is coLinux self-hosting, that is, can I build coLinux on a
CMS> running (and stable) coLinux system?
I did it sucessfully with 0.5.4
(I used Debian 1gb image,updated from Debian Woody 3.r1 CDs and
heavily patched cobuild.sh)
(but you need modern(2.95 wasn't worked for me) GCC/binutils installed FI=
RST and build
cross-development CYGWIN toolchain after than



--=20
=D1 =F3=E2=E0=E6=E5=ED=E8=E5=EC,
 Dmitriy                          mailto:dm...@ka...

RE: [coLinux-devel] Getting started building coLinux.

[Sean B. <sea...@so...>]

> -----Original Message-----
> From: col...@li... 
> [mailto:col...@li...] On Behalf 
> Of Clemmitt M. Sigler
> Sent: Monday, March 15, 2004 9:33 PM
> To: col...@li...
> Subject: [coLinux-devel] Getting started building coLinux.
> 
> 
> Hi all,
> 
> I've read the building and cygwin-cross-build files in the 
> source tarball's doc directory in preparation for trying out 
> a build.  But I have some *really* dumb questions, if anyone 
> would be willing to answer them:
> 
> 1.) I couldn't find this in the building file but, if I understand 
> correctly, the build system for both the coLinux kernel 
> (vmlinux) and the OS daemons and support code is 
> i686-pc-linux.  IOW, you build everything on a running Linux 
> system, not under Windows.  Is this correct?
I would say this is correct. The build host is ???-??-linux.
Creating the cygwin tool chain enables cross compiling to a
a i686-pc-cygwin target

> 
> 2.) Is coLinux self-hosting, that is, can I build colinux on 
> a running (and stable) coLinux system?
Yes, and I think that should be your intention. colinux is
stable enough to do that (use a binary to begin?). 
IMO it goes to avoid some pitfalls like using different 
versions of gcc and compiling modules inside colinux with
headers different from that which you used to compile the
kernel.

> 
> 3.) Is it dumb to ask if it's possible to use MinGW rather 
> than Cygwin to do builds?  I know about using Cygwin and 
> MinGW on Windows as a shell and build environment, but I 
> don't have any experience using them as a build tool platform 
> under Linux.  I do at least see that w32api from MinGW is 
> being used....
This might be interesting. I don't know why though. IMO it is
best to keep the build environment the same as the devs.

> 
> If I have time to work on building, I'll add the info I learn 
> along the way to the Wiki.  TIA.
> 
> 					Clemmitt Sigler
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President 
> and CEO of GenToo technologies. Learn everything from 
> fundamentals to system 
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> _______________________________________________
> coLinux-devel mailing list
> coL...@li...
> https://lists.sourceforge.net/lists/listinfo/colinux-devel
> 

RE: [coLinux-devel] Getting started building coLinux.

[<ch...@to...>]

>> 3.) Is it dumb to ask if it's possible to use MinGW rather
>> than Cygwin to do builds?  I know about using Cygwin and
>> MinGW on Windows as a shell and build environment, but I
>> don't have any experience using them as a build tool platform
>> under Linux.  I do at least see that w32api from MinGW is
>> being used....
> This might be interesting. I don't know why though. IMO it is
> best to keep the build environment the same as the devs.
>

To the best of my knowlege. If the cygwin1.dll is needed for the posix
layer it provides then It would not be possible to build under MinGW.
MinGW is just a port of GCC to windows for programing with the windows api
Cygwin provides a posix layer for easy porting of *NIX programs to
windows.

If the posix layer is not needed then MinGW would be the better build
environment so that the cygwin1.dll is not required. The cygwin1.dll is
very sensitive to having multiple versions on machines. I do not know if
backwards compatibility is always maintained so it may not always be as
simple as replacing cygwin1.dll in either coLinux or the cygwin install
with the newer one.

chris

Re: [coLinux-devel] Getting started building coLinux.

[tei <42...@in...>]

ch...@to... escribió:

>>>3.) Is it dumb to ask if it's possible to use MinGW rather
>>>than Cygwin to do builds?  I know about using Cygwin and
>>>MinGW on Windows as a shell and build environment, but I
>>>don't have any experience using them as a build tool platform
>>>under Linux.  I do at least see that w32api from MinGW is
>>>being used....
>>
>>This might be interesting. I don't know why though. IMO it is
>>best to keep the build environment the same as the devs.
>>
> 
> 
> To the best of my knowlege. If the cygwin1.dll is needed for the posix
> layer it provides then It would not be possible to build under MinGW.
> MinGW is just a port of GCC to windows for programing with the windows api
> Cygwin provides a posix layer for easy porting of *NIX programs to
> windows.
> 
> If the posix layer is not needed then MinGW would be the better build
> environment so that the cygwin1.dll is not required. The cygwin1.dll is
> very sensitive to having multiple versions on machines. I do not know if
> backwards compatibility is always maintained so it may not always be as
> simple as replacing cygwin1.dll in either coLinux or the cygwin install
> with the newer one.
> 
> chris
> 

Hi!

<offtopic>
<info about cygwin>

The need for cygwin1.dll is optional. You can build the same binary from 
  MinGW and Cygwin. Except.. Cygwin provice some extra features on 
Cygwin1.dll, of course, If you use that features, you need that dll.

So, MinGW is cool (the Min means minimal?), and Cygwin is cool. Both are 
cool.

note:
You may already know that, this is a reminder for others.

</info about cygwin>
</offtopic>

Re: [coLinux-devel] Getting started building coLinux.

[Ballard J. <sac...@ho...>]

> >>>3.) Is it dumb to ask if it's possible to use MinGW rather
> >>>than Cygwin to do builds?

> The need for cygwin1.dll is optional.

It is possible to use only MinGW.  Currently, the source code uses standard
C (stdlib, stdio, etc) conventions and Microsoft API's only have limited
implementation of such conventions.  Microsoft has an optional run-time
library, installed on demand like cygwin1.dll, that could be used intead of
Cygwin or MinGW but the benefits does not change because an extra *.dll file
was required.  The best option is to rewrite the portions of the coLinux
source to use only the native DDK and PlatformSDK conventions and
procedures.  I do not see such change as a priority issue at this time.  As
coLinux becomes more secure, I project the rewrite to more native OS code to
happen.  The standard C conventions are easier use at this time --
especially for those that program with linux more.

Re: [coLinux-devel] Getting started building coLinux.

[Steven E. <ste...@ya...>]

--- Ballard Jonathan <sac...@ho...> wrote:
> It is possible to use only MinGW.  Currently, the source code uses
> standard
> C (stdlib, stdio, etc) conventions and Microsoft API's only have
> limited
> implementation of such conventions.  Microsoft has an optional
> run-time
> library, installed on demand like cygwin1.dll, that could be used
> intead of
> Cygwin or MinGW but the benefits does not change because an extra
> *.dll file
> was required.  The best option is to rewrite the portions of the
> coLinux
> source to use only the native DDK and PlatformSDK conventions and
> procedures.  I do not see such change as a priority issue at this
> time.  As
> coLinux becomes more secure, I project the rewrite to more native OS
> code to
> happen.  The standard C conventions are easier use at this time --
> especially for those that program with linux more.

You could do it from a Mingw-Cross compiler on Linux. I think one of
our developers was able to build CoLinux using the Mingw linker rather
than linking to Cygwin.

Thanks
Steven


__________________________________
Do you Yahoo!?
Yahoo! Mail - More reliable, more storage, less spam
http://mail.yahoo.com

Re: [coLinux-devel] Getting started building coLinux.

[Ballard J. <sac...@ho...>]

Subject: Re: [coLinux-devel] Getting started building coLinux.


> --- Ballard Jonathan <sac...@ho...> wrote:
> > It is possible to use only MinGW.  Currently, the source code uses
[...]
>
> You could do it from a Mingw-Cross compiler on Linux. I think one of
> our developers was able to build CoLinux using the Mingw linker rather
> than linking to Cygwin.

I heavily modified and compiled coLinux sources, headers, and a portion of
the linux system without GCC, cygwin or MinGW.  I used Microsoft Development
Environment (MDE).  I reached a point where some linux sources were
specifically written for GCC style compilers and that made it very tedious.
I didn't have the time to rewrite the sources to be more portable.  I know
it is possible to compile without cygwin.  I think the 2004 version of MDE,
with updates, would make it a bit easier since it includes some of the
recent C standards.  For a less expensive immediate alternative, I suggest
to grab a coLinux binary and use GCC and either cygwin or MinGW.