This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
RE: Building the Host tools on Windows
- To: 'Jonathan Larmour' <jlarmour at redhat dot com>, Srdjan Sobajic <srdjans at digitalpersona dot com>
- Subject: RE: [ECOS] Building the Host tools on Windows
- From: Srdjan Sobajic <srdjans at digitalpersona dot com>
- Date: Wed, 16 May 2001 19:20:36 -0700
- Cc: 'eCos' <ecos-discuss at sources dot redhat dot com>
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