Thanks!

Using your suggestions and a little experimentation I could compile it
successfully with VS2010.

Instead of the old msvcrt.lib, I have used the one supplyed with the WinDDK
+ the corresponding msvcrt_winxp.obj (both files in the WinDDK). I have
renamed it to msvcrt60.lib and then copied it to the vc/lib directory. The
only modification I had to make to the code was renaming the stat calls to
_stat, and including the old sys/stat.h from the WinDDK. The normal stat
calls caused unresolved externals during linking (___imp__stat64i32).

Now, I have neko and the gc, both of them dependent only on msvcrt.dll. The
WinDDK method is detailed here:
http://kobyk.wordpress.com/2007/07/20/dynamically-linking-with-msvcrtdll-using-visual-c-2005/

Maybe I will write a small step-by-step tutorial to save the trouble for
newcomers willing to hack on Neko.

Thanks for the help!


On Fri, Feb 25, 2011 at 8:21 PM, Robin Palotai <[email protected]>wrote:

> Basically you could compile using VS Express 2010 after importing the
> project and auto-upgrading it. The same can be achieved from command
> line by starting a vs command shell and using msbuild (maybe after
> using vcbuild upgrade, but the msbuild command tells that).
>
> One show stopper could be the way the current vsproj files are built -
> the disable linking the current MSVCR and add a manual link dependency
> to MSVCR60.lib, which is legacy (but still the most common denomitor
> of Windows systems). If you have a VS6 lying around somewhere maybe
> you can get that lib (the dll should be around somewhere in the side
> by side folders I think).
>
> the ftol(2) function name/signature/something changed with the newer
> MSVCRs, possibly that's why it can't find it.
>
> Alternatively for building neko against newer MSVCR you may observe my
> beginning steps for win-x64 compilation at
> https://github.com/robinp/neko/tree/win32-x64 . I modified some neko
> sources adding ifdefs, including a NEKO_NEW_VCCRT define.
>
> Also see http://comments.gmane.org/gmane.comp.lang.neko.general/2122
>
> Robin
>
> On Fri, Feb 25, 2011 at 11:23 AM, Alexander Konotop
> <[email protected]> wrote:
> > В Thu, 24 Feb 2011 22:10:11 +0100
> > Divós György <[email protected]> пишет:
> >
> >> Hi
> >>
> >> I am new to Neko and I have been running into problems when trying to
> >> compile it. Can you provide me a step-by-step instructions on
> >> compilation for win32? I have solid C knowledge, but I don't really
> >> know how neko is organized. The buildfiles always fail with linker
> >> errors like:
> >>
> >> 1>------ Build started: Project: nekovm_dll, Configuration: Release
> >> 1>Win32
> >> ------
> >> 1>Build started 2/24/2011 10:07:31 PM.
> >> 1>InitializeBuildStatus:
> >> 1>  Touching "Release\nekovm_dll.unsuccessfulbuild".
> >> 1>ClCompile:
> >> 1>  All outputs are up-to-date.
> >> 1>C:\Program
> >> Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(990,5):
> >> warning MSB8012:
> >> TargetPath(c:\Downloads\neko-1.8.1\vm\Release\nekovm_dll.dll) does
> >> not match the Linker's OutputFile property value
> >> (c:\Downloads\neko-1.8.1\bin\neko.dll). This may cause your project
> >> to build incorrectly. To correct this, please make sure that
> >> $(OutDir), $(TargetName) and $(TargetExt) property values match the
> >> value specified in %(Link.OutputFile).
> >> 1>C:\Program
> >> Files\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets(992,5):
> >> warning MSB8012: TargetName(nekovm_dll) does not match the Linker's
> >> OutputFile property value (neko). This may cause your project to
> >> build incorrectly. To correct this, please make sure that $(OutDir),
> >> $(TargetName) and $(TargetExt) property values match the value
> >> specified in %(Link.OutputFile).
> >> 1>Link:
> >> 1>     Creating library ../bin/neko.lib and object ../bin/neko.exp
> >> 1>builtins.obj : error LNK2019: unresolved external symbol __ftol2_sse
> >> referenced in function _builtin_int
> >> 1>interp.obj : error LNK2019: unresolved external symbol
> >> 1>__imp____iob_func
> >> referenced in function _neko_vm_alloc
> >> 1>load.obj : error LNK2019: unresolved external symbol
> >> 1>__imp___stat64i32
> >> referenced in function _stat
> >> 1>../bin/neko.dll : fatal error LNK1120: 3 unresolved externals
> >> 1>
> >> 1>Build FAILED.
> >>
> >> I have managed to compile gc.lib and place it to the location where
> >> the project files are looking for it. However, I am stuck with these
> >> linker errors.
> >> I don't even know where to begin resolving them. Its evindent that I
> >> am doing it wrong, but since there are no instructions, I just try
> >> and fail.
> >>
> >> Thanks for your help!
> >>
> >> Gyorgy
> >
> > I've just looked at the files in the neko sources archive and I saw a
> > file named Makefile. You can use it (probably with some changes) if You
> > build with mingw-gcc. If You build with msvcpp - look at the files in
> > folders of the archive, there are lots of *.vcproj files. I think You
> > should just open them in msvcpp IDE and push "compile" (or smth like
> > that).
> >
> > But! This:
> >> referenced in function _neko_vm_alloc
> >> 1>load.obj : error LNK2019: unresolved external symbol
> > makes me think that You still didn't screw the libgc on msvcpp
> > correctly since "alloc" in function name makes me think about memory
> > assignment/allocation. Did You use the libgc header files (not only
> > binaries)?
> >
> > P.S. Probably I'm not a best advicer in this question since I've never
> > built neko myself neither in *nix/gcc nor in windows/msvcpp/mingw. So
> > don't mention my answer too much - above are just some thoughts.
> >
> > --
> > Neko : One VM to run them all
> > (http://nekovm.org)
> >
>
> --
> Neko : One VM to run them all
> (http://nekovm.org)
>
-- 
Neko : One VM to run them all
(http://nekovm.org)

Reply via email to