RE: [ECOS] Building the Host tools on Windows

RE: [ECOS] Building the Host tools on Windows

[Srdjan Sobajic]

So I grabbed the latest stuff from CVS this morning and everything works
like a charm!
Thanks!

BTW. I think that there are two really minor issues still:

1) The splsh16.bmp image in the host\tools\configtool\standalone\win32\res
directory
is messed up. Please check it out and take a look. (there is a shift of the
middle section
of the image to the right.)

2) When building the Configtool project (the one thats build using VC),
there are some warnings
about the help files not being there... I guess it's to be expected.

I've added some responses to your comment below:

> > 1. When getting the eCos sources from CVS using WinCVS, it 
> appears necessary
> > 
> > to set the CRLF translation (in the Global Settings dialog) 
> to UNIX mode for
> > 
> > getting the eCos package subdirectory, and to DOS mode for 
> getting the host
> > subdirectory. If you check out the host tools under UNIX 
> mode, VC can't open
> > 
> > the .dsw. Effectively, you can't get the whole thing in one pass...
> 
> Things may be different with the command-line cvs client - or 
> did you make
> WinCVS use that?

I just used WinCVS in the default mode (so no command line client). I will
have to try
that sometime, but for now, I think this should be made a little clearer.

> > Also, make sure you have installed VC6 with all the MFC 
> options. On my
> > machine, I needed mfc42u.lib, which is the Unicode version 
> of MFC, and which
> > 
> > may not be installed by default everywhere.
> 
> We always ship the ANSI build - for Win95/98/ME 
> compatibility. We always
> develop with the Unicode version to catch Unicode/ANSI conversion bugs
> early. If you switch to the ANSI release configuration, you 
> need mfc42.lib,
> not mfc42u.lib, etc.

OK. It works just fine as you said if I choose the ANSI release build.

> > 7. In VC6, once the project has been loaded, look at the 
> files in the "cdl"
> > project. Specifically, open the settings (by right clicking) for the
> > ChangeLog
> > file. In the "Custom Build" tab, edit the command line (at 
> the end) to point
> > 
> > to the proper TCL installation directories. Specifically, 
> it is necessary to
> > 
> > set
> > --with-tcl_version=83 --with-tcl-lib=/c/tcl/lib
> > --with-tcl-header=/c/tcl/include
> > 
> > ** NOTE Even after doing this, during the configure steps I 
> see configure
> > picking up tcl from /usr/lib.
> 
> This aspect should be fixed in the anon cvs update. The 
> custom build step
> shold be able to refer to the TCLHOME variable.


Yep, It works wonderfully now. Picks up everything from TCLHOME correctly. 
I just need to set the TCL version information correctly throughout the
projects.

BTW, do you think it'd be worth having a TCLVERSION env variable to set the
version
throughout the projects, so that the VC linker will get the right version of
the tcl8x.lib
and so that you don't have to mess around the custom build step parameters?
Especially, since you
have to change it on every project and for all configurations... (I know,
no-one is going build
the other configurations, but still....)

If you're still interested I can send you a diff vs the README file. Should
I?

Srdjan

Re: [ECOS] Building the Host tools on Windows

[Jonathan Larmour]

Srdjan Sobajic wrote:
> 
> So I grabbed the latest stuff from CVS this morning and everything works
> like a charm!

Excellent.

> BTW. I think that there are two really minor issues still:
> 
> 1) The splsh16.bmp image in the host\tools\configtool\standalone\win32\res
> directory
> is messed up. Please check it out and take a look. (there is a shift of the
> middle section
> of the image to the right.)

Ah, I had a look and the .bmp files are not marked as being binary files in
the repository. This meant the CVS client tried to perform LF->CRLF
conversion on them! I've fixed that now. 
 
> 2) When building the Configtool project (the one thats build using VC),
> there are some warnings
> about the help files not being there... I guess it's to be expected.

For now, I'm afraid so.
 
> I've added some responses to your comment below:
> 
> > > 1. When getting the eCos sources from CVS using WinCVS, it
> > appears necessary
> > >
> > > to set the CRLF translation (in the Global Settings dialog)
> > to UNIX mode for
> > >
> > > getting the eCos package subdirectory, and to DOS mode for
> > getting the host
> > > subdirectory. If you check out the host tools under UNIX
> > mode, VC can't open
> > >
> > > the .dsw. Effectively, you can't get the whole thing in one pass...
> >
> > Things may be different with the command-line cvs client - or
> > did you make
> > WinCVS use that?
> 
> I just used WinCVS in the default mode (so no command line client). I will
> have to try
> that sometime, but for now, I think this should be made a little clearer.

The command line client doesn't distinguish between "DOS" and "Unix" mode.
I don't know what corresponds to what winCVS does, but I suspect you could
probably check out everything in DOS mode. In our normal releases, we ship
our sources in a Windows friendly format (i.e. with CRLFs).
 
> Yep, It works wonderfully now. Picks up everything from TCLHOME correctly.
> I just need to set the TCL version information correctly throughout the
> projects.
> 
> BTW, do you think it'd be worth having a TCLVERSION env variable to set the
> version
> throughout the projects, so that the VC linker will get the right version of
> the tcl8x.lib
> and so that you don't have to mess around the custom build step parameters?

I think that would be useful, yes. If you're interested in doing this, send
us the patch. Although if the patch is quite large, we may need a copyright
assignment: http://sources.redhat.com/ecos/faq.html#contrib_assign

> If you're still interested I can send you a diff vs the README file. Should
> I?

That would definitely be useful. Thanks!

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] Building the Host tools on Windows

[Fabrice Gautier]

On Fri, 18 May 2001 02:09:38 +0100
Jonathan Larmour <jlarmour@redhat.com> wrote:
>  
> > 1. When getting the eCos sources from CVS using WinCVS, it appears necessary
> > to set the CRLF translation (in the Global Settings dialog) to UNIX mode for
> > getting the eCos package subdirectory, and to DOS mode for getting the host
> > subdirectory. If you check out the host tools under UNIX mode, VC can't open
> > the .dsw. Effectively, you can't get the whole thing in one pass...
> 
> Things may be different with the command-line cvs client - or did you make
> WinCVS use that?

With cvs command line it depends wether your mount point is binary or
text (binary -> Unix mode, text -> Dos mode)

regards,

-- 
Fabrice Gautier <gautier@email.enstfr>

Re: [ECOS] Building the Host tools on Windows

[Jonathan Larmour]

Srdjan Sobajic wrote:
> 
> I've encountered several "gotchas" in trying to build the host tools. I'll
> try
> to outline them below, and maybe you can give me your input on stuff that
> I'm
> doing wrong. I _have_ managed to compile all the tools finally, and they
> seem
> to work fine.

Good :-).

> Once I have understood what's really necessary here, I'll be
> more than willing to write up the README for this. (This is already written
> in
> a README style-- I don't mean to sound patronizing.)
> 
> Here goes:
> 
> 0. All of the following applies on a machine which has W2K, the latest
> Cygwin
> (1.3.1), latest (today's=5/16) eCos source from CVS, WinCVS 1.2, Tcl/Tk 8.3
> from Scriptics and VC6SP5.

I'm going to be checking in an update to anon CVS today or (more likely)
tomorrow which should improve some of the issues with the location of TCL.
Have a go at updating to that version and check it all still works for you!
 
> 1. When getting the eCos sources from CVS using WinCVS, it appears necessary
> 
> to set the CRLF translation (in the Global Settings dialog) to UNIX mode for
> 
> getting the eCos package subdirectory, and to DOS mode for getting the host
> subdirectory. If you check out the host tools under UNIX mode, VC can't open
> 
> the .dsw. Effectively, you can't get the whole thing in one pass...

Things may be different with the command-line cvs client - or did you make
WinCVS use that?

> 2. To build the host tools, it's necessary to set the TCLHOME environment
> variable to the root of the TCL installation. The root of the TCL
> installation
> is the directory which _contains_ the lib, include, bin directories. This is
> 
> best done in the System Properties->Advanced->Environment Variables Dialog
> in
> Windows. (TCLHOME = c:\tcl)
> 
> 3. Since the .dsw as shipped assumes building to the V:\ drive, rather than
> changing all the settings, it is easier to do a "SUBST V:\ C:\temp" command
> from the Windows Command shell. This creates a virtual V:\ drive. C:\temp
> above should be changed to an exisiting path where the build will be stored.
> 
> 4. In the VC Tools->Options->Directories tab, make sure the following are in
> 
> the paths:
> 
> Under "Executable files" -> c:\cygwin\bin (Or your proper location)
> Under "Include files" - c:\tcl\include,
>            c:\program files\microsoft platform sdk\include

Or c:\Program Files\HTML Help Workshop\include

> Under "Library files" - c:\tcl\lib
>            c:\program files\microsoft platform sdk\lib

Or c:\Program Files\HTML Help Workshop\lib

> (The Platform SDK is necessary (it seems!) for the htmlhelp.h header file
> and
> associated library.)

Or the HTML Help Workshop :-).

> Also, make sure you have installed VC6 with all the MFC options. On my
> machine, I needed mfc42u.lib, which is the Unicode version of MFC, and which
> 
> may not be installed by default everywhere.

We always ship the ANSI build - for Win95/98/ME compatibility. We always
develop with the Unicode version to catch Unicode/ANSI conversion bugs
early. If you switch to the ANSI release configuration, you need mfc42.lib,
not mfc42u.lib, etc.

> 5. Depending on which version of TCL you have installed, you may need to
> change the Settings for the Configtool project. (The cdl project and
> ecosconfig project are build using GNU make + VC. The Configtool project is
> built using the VC6 default build processes.) To do this, right-click on
> "Configtool project" in the workspace window, and select Settings. Click on
> the Link tab, and look through the library list. If you have tcl82.lib
> installed (Tcl 8.2) then the default should be OK. If you have a different
> revision (which is located in $TCLHOME\lib), you should update the name
> here.
> (i.e. change to tcl83.lib)
> 
> **PLEASE CHECK WHAT FOLLOWS-- I'm sure that this is not quite right***
> 
> 6. The default compiler settings for building the Configtool project (just
> that project, not the workspace) are Level 4 warnings. This results in 1936
> warnings when building on my machine. I'd reccomend people to turn off
> warnings when building... (BTW I think most of them are benign, but...)


Most warnings result from STL header compilation. Most are benign, none are
critical.

> 7. In VC6, once the project has been loaded, look at the files in the "cdl"
> project. Specifically, open the settings (by right clicking) for the
> ChangeLog
> file. In the "Custom Build" tab, edit the command line (at the end) to point
> 
> to the proper TCL installation directories. Specifically, it is necessary to
> 
> set
> --with-tcl_version=83 --with-tcl-lib=/c/tcl/lib
> --with-tcl-header=/c/tcl/include
> 
> ** NOTE Even after doing this, during the configure steps I see configure
> picking up tcl from /usr/lib.

This aspect should be fixed in the anon cvs update. The custom build step
shold be able to refer to the TCLHOME variable.

> If you start the build at this point everything should be OK, except:
> 
> Actually, this is where I really did something bad... I got an error in the
> linking of ecosconfig.exe about tcl83.lib not being found. So I looked
> through
> the linker command line, saw which directories were being searched for for
> .libs, and just cut and pasted tcl83.lib into one of them. I'm sure that
> this
> is not quite what was intended, but it works.

Again, hopefully this will be fixed with the anon cvs update.
 
Hopefully with your help we can work to make sure others don't get the same
problems in future!

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

RE: [ECOS] Building the Host tools on Windows

[Srdjan Sobajic]

Hi Jonathan,

I've encountered several "gotchas" in trying to build the host tools. I'll
try 
to outline them below, and maybe you can give me your input on stuff that
I'm 
doing wrong. I _have_ managed to compile all the tools finally, and they
seem 
to work fine. Once I have understood what's really necessary here, I'll be 
more than willing to write up the README for this. (This is already written
in 
a README style-- I don't mean to sound patronizing.)

Here goes:

0. All of the following applies on a machine which has W2K, the latest
Cygwin 
(1.3.1), latest (today's=5/16) eCos source from CVS, WinCVS 1.2, Tcl/Tk 8.3 
from Scriptics and VC6SP5.

1. When getting the eCos sources from CVS using WinCVS, it appears necessary

to set the CRLF translation (in the Global Settings dialog) to UNIX mode for

getting the eCos package subdirectory, and to DOS mode for getting the host 
subdirectory. If you check out the host tools under UNIX mode, VC can't open

the .dsw. Effectively, you can't get the whole thing in one pass...

2. To build the host tools, it's necessary to set the TCLHOME environment 
variable to the root of the TCL installation. The root of the TCL
installation 
is the directory which _contains_ the lib, include, bin directories. This is

best done in the System Properties->Advanced->Environment Variables Dialog
in 
Windows. (TCLHOME = c:\tcl)

3. Since the .dsw as shipped assumes building to the V:\ drive, rather than 
changing all the settings, it is easier to do a "SUBST V:\ C:\temp" command 
from the Windows Command shell. This creates a virtual V:\ drive. C:\temp 
above should be changed to an exisiting path where the build will be stored.

4. In the VC Tools->Options->Directories tab, make sure the following are in

the paths:

Under "Executable files" -> c:\cygwin\bin (Or your proper location)
Under "Include files" - c:\tcl\include,
           c:\program files\microsoft platform sdk\include
Under "Library files" - c:\tcl\lib
           c:\program files\microsoft platform sdk\lib

(The Platform SDK is necessary (it seems!) for the htmlhelp.h header file
and 
associated library.)

Also, make sure you have installed VC6 with all the MFC options. On my 
machine, I needed mfc42u.lib, which is the Unicode version of MFC, and which

may not be installed by default everywhere.

5. Depending on which version of TCL you have installed, you may need to 
change the Settings for the Configtool project. (The cdl project and 
ecosconfig project are build using GNU make + VC. The Configtool project is 
built using the VC6 default build processes.) To do this, right-click on 
"Configtool project" in the workspace window, and select Settings. Click on 
the Link tab, and look through the library list. If you have tcl82.lib 
installed (Tcl 8.2) then the default should be OK. If you have a different 
revision (which is located in $TCLHOME\lib), you should update the name
here. 
(i.e. change to tcl83.lib)

**PLEASE CHECK WHAT FOLLOWS-- I'm sure that this is not quite right***

6. The default compiler settings for building the Configtool project (just 
that project, not the workspace) are Level 4 warnings. This results in 1936 
warnings when building on my machine. I'd reccomend people to turn off 
warnings when building... (BTW I think most of them are benign, but...)

7. In VC6, once the project has been loaded, look at the files in the "cdl" 
project. Specifically, open the settings (by right clicking) for the
ChangeLog 
file. In the "Custom Build" tab, edit the command line (at the end) to point

to the proper TCL installation directories. Specifically, it is necessary to

set
--with-tcl_version=83 --with-tcl-lib=/c/tcl/lib 
--with-tcl-header=/c/tcl/include

** NOTE Even after doing this, during the configure steps I see configure 
picking up tcl from /usr/lib.

If you start the build at this point everything should be OK, except:

Actually, this is where I really did something bad... I got an error in the 
linking of ecosconfig.exe about tcl83.lib not being found. So I looked
through 
the linker command line, saw which directories were being searched for for 
.libs, and just cut and pasted tcl83.lib into one of them. I'm sure that
this 
is not quite what was intended, but it works.

Well, I think that's it.

If anyone has any input on this, I'd really appreciate it...

Srdjan




>===== Original Message From Jonathan Larmour <SMTP:jlarmour@redhat.com>
=====
>Srdjan Sobajic wrote:
>>
>> I'm trying to build the host tools on Windows in Visual Studio 6.
>[snip]
>> It seems that the build is using the cygwin headers for "Types.h" and
some
>> other system headers and,
>> on the other hand, relying on VCs internal headers for STL. I haven't 
really
>> found much documentation
>> other than "Open the project in VS and build." for the tools, so I was
>> wondering if anyone could shed
>> some light on this. (I grabbed the sources from CVS the yesterday(?).)
>
>It shouldn't be using cygwin's sys/types.h at all. What is potentially
>happening is that the search for a Tcl installation is picking up the
>cygwin version of Tcl. For a VC++ build, this isn't meant to happen; but
>Bart just happened to be looking at this today and has checked some fixes
>into our internal source tree to prevent it happening in future.
>
>But for you right now, what you need to do is make sure that in the custom
>build step in VC++, the libcdl configure macro is invoked with a --with-tcl
>argument that points to a valid installation of Scriptics TCL.
>
>Once you do get going, I'd be interested if you could submit a patch for
>the README to clarify the areas where you think it could be improved.
>
>Jifl
>--
>Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
>Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

Re: [ECOS] Building the Host tools on Windows

[Jonathan Larmour]

Srdjan Sobajic wrote:
> 
> I'm trying to build the host tools on Windows in Visual Studio 6.
[snip] 
> It seems that the build is using the cygwin headers for "Types.h" and some
> other system headers and,
> on the other hand, relying on VCs internal headers for STL. I haven't really
> found much documentation
> other than "Open the project in VS and build." for the tools, so I was
> wondering if anyone could shed
> some light on this. (I grabbed the sources from CVS the yesterday(?).)

It shouldn't be using cygwin's sys/types.h at all. What is potentially
happening is that the search for a Tcl installation is picking up the
cygwin version of Tcl. For a VC++ build, this isn't meant to happen; but
Bart just happened to be looking at this today and has checked some fixes
into our internal source tree to prevent it happening in future.

But for you right now, what you need to do is make sure that in the custom
build step in VC++, the libcdl configure macro is invoked with a --with-tcl
argument that points to a valid installation of Scriptics TCL.

Once you do get going, I'd be interested if you could submit a patch for
the README to clarify the areas where you think it could be improved.

Jifl
-- 
Red Hat, Rustat House, Clifton Road, Cambridge, UK. Tel: +44 (1223) 271062
Maybe this world is another planet's Hell -Aldous Huxley || Opinions==mine

[ECOS] Building the Host tools on Windows

[Srdjan Sobajic]

Hi, 

I'm trying to build the host tools on Windows in Visual Studio 6.

I think that I've finally managed to set everything up correctly so that the
build process starts, 
(This included adding C:\cygwin\bin to VCs "Executable" directory list), but
I am getting a lot
of syntax errors.

It seems that the build is using the cygwin headers for "Types.h" and some
other system headers and,
on the other hand, relying on VCs internal headers for STL. I haven't really
found much documentation
other than "Open the project in VS and build." for the tools, so I was
wondering if anyone could shed
some light on this. (I grabbed the sources from CVS the yesterday(?).)


Thanks for your help!

Srdjan




------
The log of the build follows....
(If you want the whole log, let me know.)


make[3]: Leaving directory `/cygdrive/v/cdl/Release/build/libcdl/testsuite'
make[2]: Leaving directory `/cygdrive/v/cdl/Release/build/libcdl/testsuite'
make[2]: Entering directory `/cygdrive/v/cdl/Release/build/libcdl'
cl -nologo -W3 -GR -GX -MD -O2 -DHAVE_CONFIG_H -I.
-I/usr/local/ecos/host/libcdl -I. "-Ic:/ecos/host/libcdl"
"-Iv:/cdl/Release/build/infra" "-IC:/cygwin/usr/include"     -c `cygpath -w
/usr/local/ecos/host/libcdl/interp.cxx`
interp.cxx
C:/cygwin/usr/include\sys/types.h(112) : error C2632: 'long' followed by
'long' is illegal
C:/cygwin/usr/include\sys/types.h(113) : error C2632: 'long' followed by
'long' is illegal
C:/cygwin/usr/include\sys/reent.h(213) : error C2632: 'long' followed by
'long' is illegal
C:/cygwin/usr/include\sys/reent.h(213) : error C2144: syntax error : missing
';' before type 'unsigned long'
C:/cygwin/usr/include\sys/reent.h(213) : error C2501: '__extension__' :
missing storage-class or type specifiers
C:/cygwin/usr/include\stdlib.h(48) : error C2733: second C linkage of
overloaded function 'atexit' not allowed
        C:/cygwin/usr/include\stdlib.h(48) : see declaration of 'atexit'
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\iosfwd(73) : error
C2065: 'mbstate_t' : undeclared identifier
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\iosfwd(82) : error
C2146: syntax error : missing ';' before identifier 'state_type'
        C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\iosfwd(135) :
see reference to class template instantiation 'std::char_traits<_E>' being
compiled
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\iosfwd(82) : error
C2501: 'state_type' : missing storage-class or type specifiers
        C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\iosfwd(135) :
see reference to class template instantiation 'std::char_traits<_E>' being
compiled
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\iosfwd(140) : error
C2146: syntax error : missing ';' before identifier 'int_type'
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\iosfwd(140) : error
C2501: 'int_type' : missing storage-class or type specifiers
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\iosfwd(143) : error
C2146: syntax error : missing ';' before identifier 'state_type'
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\iosfwd(143) : error
C2501: 'state_type' : missing storage-class or type specifiers
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\iosfwd(163) : error
C2143: syntax error : missing ',' before '&'
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\iosfwd(163) : error
C2059: syntax error : '&'
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\iosfwd(165) : error
C2143: syntax error : missing ';' before '__cdecl'
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\iosfwd(166) : warning
C4183: 'to_int_type': member function definition looks like a ctor, but name
does not match enclosing class
C:\Program Files\Microsoft Visual Studio\VC98\INCLUDE\iosfwd(167) : error
C2143: syntax error : missing ',' before '&'