[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gnash-dev] Compilation trouble on Windows with MSVC
|
From: |
Eric Hughes |
|
Subject: |
Re: [Gnash-dev] Compilation trouble on Windows with MSVC |
|
Date: |
Tue, 12 Jun 2007 12:36:16 -0600 |
At 11:24 AM 6/12/2007, Asger Ottar Alstrup wrote:
I'm trying to compile Gnash on Windows, using Microsoft Visual Studio 8. I
added libgeometry to the include path, but I still get 204 errors.
I've been through this once, two months ago when I started on this
project. I didn't finish. I've been working on cygnal since, and have not
yet turned back, trying (and failing) to get a new prototype out before
release. I haven't worked on it since.
Here are the basic issues:
1. The tool chain that configuration uses can't be expected to work
correctly for a typical VS8 user. I'm using it myself for this
project. The essential reason is, that even if mingw/msys or cygwin are
installed, is that installation of VS8 doesn't put the compiler (by
default) on the search path. The upshot of this is that config.h doesn't
get made. I've appended one that I made. I can't guarantee that it works.
2. There are a large number of dependencies that are typical for *x
systems which are not for win32. I tracked them down (I _think_ all of
them). You'll have to install both binaries (libraries) as well as sources
(headers) and get all the path configurations correct. It's a big
pain. I've also appended a draft of a document about all that.
3. The ordinary build environment assumes a lot of included directory paths
within the gnash code. You'll need to add them all to your project file
(if you're using one).
As to some specific problems:
(i) ARRAYSIZE is already defined in a windows header. Wrapping its gnash
definition in #ifndef/#endif seems to fix the problem, since it has
essentially the same meaning. Personally, I'd rather see an inline
template function, which would be more type-safe, but I didn't consider it
a high enough priority to put in the requisite effort to all get the
details right.
(ii) Use the following definition for VC8:
# define __PRETTY_FUNCTION__ __FUNCDNAME__
__FUNCDNAME__ is the Microsoft-specific version of this. You can put this
in source or as a command line definition in the project file.
Eric
===========================================================================
//
// Copyright (C) 2007 Free Software Foundation, Inc.
//
// This file is part of GNU Cygnal.
//
// This program is free software; you can redistribute it and/or modify
// it under the terms of the GNU General Public License as published by
// the Free Software Foundation; either version 2 of the License, or
// (at your option) any later version.
//
// This program is distributed in the hope that it will be useful,
// but WITHOUT ANY WARRANTY; without even the implied warranty of
// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
// GNU General Public License for more details.
//
// You should have received a copy of the GNU General Public License
// along with this program; if not, write to the Free Software
// Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA
//
/* $Id: config.h $ */
/* CONFIG.H
* This header replaces config.h as autoconf would generate
it on *x systems.
* It is targeted is Visual C++ 8, as shipped (for example)
with the first Visual Studio Express.
*
* Supporting Visual Studio users means not requiring them to have cygwin
or the like installed. Without
* a full shell environment, autoconf won't run. Therefore, we provide
them the equivalent of the result
* of such a run. In the best of all possible worlds, we would not have
this problem. Contrary to
* Pangloss and G. Liebniz, we do not live in that world.
*/
#pragma once
#ifndef CONFIG_H_INCLUDED
#define CONFIG_H_INCLUDED
/* The need to define this at all is a symptom that somewhere, there's some
networking
* code in need of some portability work.
*/
#define HAVE_WINSOCK_H
/** This definition silences VC++ warning C4996: "The POSIX name for this
item is deprecated."
* Deprecated in VC++, that is.
*/
#define _SCL_SECURE_NO_DEPRECATE
/** This definition silences a VC++ warning about potentially insecure
buffer functions.
*/
#pragma warning(disable:4996)
/* This was previously in log.h, then moved into the autoconf system.
* Really, this ought to be replaced by C++ stream manipulators.
* Unfortunately, the translation tool has not been updated to reflect C++
coding practices.
*/
#if SIZEOF_SIZE_T == SIZEOF_INT // try "int" first
#define SIZET_FMT "%d"
#elif SIZEOF_SIZE_T == SIZEOF_LONG
#define SIZET_FMT "%ld"
#elif SIZEOF_SIZE_T == SIZEOF_SHORT
#define SIZET_FMT "%hd"
#endif
#define TARGET_CONFIG "win32"
#define RENDERER_CONFIG "opengl"
#define GUI_CONFIG "sdl"
#define SOUND_CONFIG "sdl"
#define DECODER_CONFIG "ffmpeg"
#define MEDIA_CONFIG "???"
#endif
===========================================================================
Compiling with Visual Studio
This document is written for an audience that is using VS Express, not the
full version. If you use the full version, there will be some things you
can ignore here, mostly about how to set up everything in Visual Studio.
Installing the Build Environment
The total build environment for compiling with Visual Studio Express
includes the following:
* The Microsoft Visual Studio environment.
* The <http://www.mingw.org/>MinGW environment.
So you ask, why? The one word answer: dependencies.
Gnash relies upon quite a large number of other software packages. As a
rule, these packages are open source, codecs being a notable and annoying
exception. Certain of these packages do not have pre-packaged support for
Visual VC++ builds. Luckily, the ones that don't are in C, not C++, and
thus can be compiled in another environment and linked in. (For those who
haven't had to deal with this, C linkage is relatively standard, but C++
linkage is expressly and purposefully not, to handle differences in
run-time implementations of exceptions, RTTI, etc.) And here's the
compatibility fact: MinGW outputs object files from C source code that are
link-compatible with Visual C++.
The upshot is that you'll have to install MinGW in order to get a Visual
C++ build from scratch. The alternative is to add VC++ build support to
the dependencies. While this is possible
Install Visual Studio Express
If, for whatever reason, you already have Visual Studio installed, you need
only skim this section.
You'll want Visual Studio Express for C++, available without charge from
Microsoft; <http://msdn.microsoft.com/vstudio/express/downloads/>download
it. Under "Additional Components", be sure to get the Service Packs that's
available as well as the Platform SDK. The Platform SDK does not come
pre-integrated with VS Express. Microsoft has separate
<http://msdn.microsoft.com/vstudio/express/visualc/usingpsdk/>installation
instructions available. Follow these; you'll need to do something similar
to compile Boost (see below).
Install MinGW
Elsewhere in this documentation, there are
<file:///C:/Documents%20and%20Settings/Eric/Desktop/gnash/win32/build_mingw.html#install>instructions
on installing MinGW.
Install Source Dependencies
Gnash uses many other packages. Some are available in source form only,
others have precompiled libraries available. All have headers that require
inclusion. For each package, there are two steps. First, obtain the
package, always the headers, and then sources and/or objects as needed.
Second, you'll need to include the package in your build process. There
are two options here:
* Global inclusion. You can make the package available to all projects
within VSE. In the dialog box reached through Tools > Options > Project
and Solutions > VC++ Directories, there is a drop-down box labelled "Show
directories for :", within which the two items of interest are "Include
files" and "Library files". Add line items here to make a package
available to all of VSE.
* Project inclusion. If you are working only on Gnash, you may alter
the project files separately. Use the Project > Properties dialog. For
include files, use C++ > General > Additional Include Directories. For
libraries, use Linker > Input > Additional Dependencies.
Boost
Boost comes in source form only. You'll have to compile it. If you've
never done this, follow the instruction at their
<http://www.boost.org/more/getting_started.html>Getting Started page. For
Visual Studio Express, you will have to separately integrate the Platform
SDK for the Boost compilation process. Follow their
<http://www.boost.org/tools/build/v1/vc-8_0-tools.html>instructions for
VC8. Obtain bjam and use "-sTOOLS=vc-8_0" on its command line.
SDL
FFmpeg
This project does not really believe in formal releases. Get the sources
straight off their Subversion server. See their
<http://ffmpeg.mplayerhq.hu/download.html>download page for details. If
you don't already use Subversion,
<http://tortoisesvn.tigris.org/>TortoiseSVN is a good way to go.
libxml2
Win32 binary compilations are available
<http://www.zlatkovic.com/pub/libxml/>here. You'll need not only libxml2,
but also iconv and zlib.
libltdl
GNU <http://www.gnu.org/software/libtool/manual.html>libtool provides
cross-platform support for dynamic libraries; libltdl is a component. The
build environment for libtool does not come with VC configuration
support. Use MinGW to compile it. It's output will be libltdl.a. Use
that name, with the .a at the end, as an additional dependency for the
linker; the linker will understand it just fine.
JPEG
The commonly used jpeg library was written by the IJG (Independent JPEG
Group). Grab and extract their distribution. Copy jconfig.vc to
jconfig.h. Copy makefile.vc to makefile and then run it with nmake, not GNU
make. If your ordinary environment does not have the compiler in PATH, make
sure to execute vcvars32.bat first. Finally, the VC++ linker looks for
jpeg.lib, not libjpeg.lib.
cURL
Elsewhere than on Win32, this is common enough not to be listed as a
widespread dependency. You can get a binary version of libcurl
<http://curl.haxx.se/download.html>here. Make sure you select the MSVC
version, not the generic version
Install Binary Dependencies
Yeah, building from source shouldn't require any of these, but they do.
libiberty
Certain functions from the GNU C Library are required, namely getopt. These
functions are available in MinGW. Put the library directory within your
MinGW installation into the library search path. The project file already
has libiberty.lib listed as a linker input.
===========================================================================