Building on Windows

Little Language
1

To date, we at BitKeeper have been building BK (and Little) with an old Mingw/msys toolchain.

Making it possible to build Little on another machine without our toolchain is a project that is as yet unassigned. Any takers?

2

Hi,

I just tried to build it with gcc 4.8.1 and mingw32-make (3.99) and it fails pretty badly.

I’m most likely missing dependencies. I’m getting a lot of “CreateProcess” fail which I suppose means it can’t run some of the commands.

From the looks of it tcl needs to run ./configure, which while its possible to get working on Windows, its quite an undertaking if you dont want to/cant use cygwin.

Usually to build autotools Linux/Posix software on Windows I end up writing a config.h by hand and building with cl.exe (which comes with Visual C++). The latest VS has a clang front-end so it can build any unixy package pretty easily - I rebuilt ffmpeg recently using it.

Considering I would need need to get tcl & tk to build I’m not sure whether I’ll have time to do it - it could take a few days of work from experience. PCRE is easy enough since its simple clean C.

Anyway, I’d like to take a look, could you publish a set of prebuilt-exe for Windows? I would like to play around with Little first. I have a multiplatform build system for C/C++/Java that has a bunch of bash script and I wanted to checkout little to build a couple of UI front-ends for it - to make it easier for new comers to do builds for our software.

Also it would help if you could document all the dependencies necessary for the build, maybe zipping the toolchain you use on Windows would help - depending how big/custom it is, I know these can get unwidely :wink:

Cheers,
Pierre

3

You’ve found a bit of an achilles heel.

We’ve been using a crusty old mingw environment for building stuff on Windows.

I’ve been toying with building under cygwin but have not yet succeeded (feel close but that doesn’t really help you).

I’ll see about adding our binary wad to the website, maybe that’ll help you bootstrap.

4

Try downloading this tar: little-lang-1.0-win32-ix86.tar.gz

For now, it’s unpublished.

To use, unpack it somewhere, it will unpack into a little-lang-1.0-win32-ix86 subdir.

Make yourself a temp.l:

int
main()
{
    printf("Hello world\n");
    return (0);
}

Then run little-lang-1.0-win32-ix86/L/bin/L.exe temp.l cross your fingers.

I was able to do the above in a cygwin window so I’m hoping that it’ll work for you. Please let me know and I’ll update the downloads page.

5

I just tested it on WinXP 32-bit and Win7 64-bit. Seems OK.

Failed to run the Linux version on a shared Debian Wheezy machine, foiled by glibc versioning.

6

Works for me on Windows. Thanks.

Can you give me a list of the dependencies required to build? what you can remember at least :wink:

I saw bison, flex and libxft2-dev in the README. I assume libxft2 is necessary for Linux only (that’s a Xwindow lib?). Bison & flex is there a specific version? there should be some Windows binaries somewhere… I haven’t used them in a while so I’m not sure what the status of those is on Windows.

7

So far, on Windows I have been able to run small scripts that I wrote and some of the example code in the src download, but I haven’t been able to get the julia.l file to run. With “L.exe julia.l”, L starts and dies without any error message. I spent a few hours fiddling with it but couldn’t localize the problem.

I’m barely familiar with Tcl/Tk, but I’m pretty sure wish isn’t working right. It won’t load files and a simple “hello world” doesn’t display.

8

So I was able to build without any of our internal crud. Here’s what I did:

  1. Install a fresh mingw/msys environment from http://www.mingw.org using the instructions found here
  2. The initial installation doesn’t include a bunch of development things so I added the things I thought I’d need (give me a simple command to generate a list and I’m more than happy to share, I just drove the gui install and didn’t really take notes about what I selected)
  3. Open an msys window for this installation (by running c:\MinGW\msys\1.0\msys.bat)
  4. Installed git for windows from https://git-for-windows.github.io
  5. Using that git (its bash window), cloned the little-lang repo from github
  6. In the msys window created in step 3, cd to the git repo and typed make
  7. Fix the build failure in tcl/generic/tclIOSock.c by removing the ifdef __MINGW32__ block at the bottom (that’s to workaround some missing definitions in the crusty old mingw that we’ve been using internally).
  8. Type make again and it just worked.

I then tried to install msys2 from http://msys2.github.io and repeat the above. The build fails because the Makefile tries to run our platform script which outputs unix, win, macosx based on the output of uname -a. Unfortunately, msys2 reports MSYS... instead of MINGW... so that fails. Fixing platform moves us onto running configure which fails spectacularly because config.guess does not grok MSYS vs MINGW as a platform name. Perhaps this is the big undertaking that you were trying to avoid? I certainly am :smiley:

So my question back to you all is: Is there a de facto standard build environment on Windows?

1 Like
9

If by “de facto standard build environment on Windows” you mean what practically everybody uses, I think MSVC++ use pretty far outnumbers mingw. I think that’s what the IUP developers use, even though they are mainly Unix people. Support for C90 is not perfect, though, let alone C99. I use Pelles C, because it’s light, simple, stable, free, and supports C11.

Further on the wish issue…I’ve found that I can run Little, Tcl, and Tcl+Little command line scripts in it, but it crashes whenever I call a Tk widget.

10

VC++ 2015 comes with a Clang front end which supports fully C99, etc… its just Clang with MSVC’s backend as code generator which allows you to debug the stuff in the Visual Studio.

11

So yes the “de-facto” build environment would be Visual Studio. I actually don’t use it (the IDE part) to build my stuff because managing VS projects with a GUI is just not a sane way of spending your free time ^^

I use something derived from Jam to build which calls MSVC++ compiler (cl.exe or the clang front end depending on the code). It’s certainly not “standard”. A fairly popular option is Cmake which works on all platforms - although I find it pretty cumbersome to use, too many intermediate steps for my taste.

Once I have some free play time I will take a look and try to repro the build with the tools you mentioned and then look at how it can be made easier - most likely using the Clang front-end in the latest VC++.

12

The developers here don’t seem to be Windows people, and Clang looked like a lot of work to get set up on Windows.

I don’t understand why more businesses don’t use the Intel compiler. It’s cheap enough that I would expect any business to save money if they are having to pay someone to spend time setting things up.

13

You are correct, we are not Windows people.

When I use the phrase build environment it’s really code for a UNIX style shell, makefile, tools, etc. IOW, a world that can run the nightmare that is autotools.

Discussions around clang vs. intel’s compiler vs VC++ kind of miss the point. Or maybe, I’m missing some other point. Wouldn’t be the first time :slight_smile:

14

I hear you about build environments. That’s why I use Pelles C if I don’t absolutely need the utilities and performance of GCC/ICC/Clang + friends.

It sounds like you would be most comfortable staying in a Cygwin environment. I wonder if the new Linux compatibility system in Windows 10 would support your accustomed environment.

15

Funny you should mention it. I was all over it and yup, since it’s basically a full Linux running under Windows it works just fine.

But it’s still very new, in beta, etc. Still kind of a cool curiousity vs something we can count on.

As to the Cygwin, well that certainly could be made to work but my attempts had problems so for expedience, I stuck with MinGW/MSYS.

Someday, it would be nice to work correctly everywhere. The path to that particular patch of unicorns, however, is unmapped.

16

MSYS2.patch.txt (800 Bytes)
fix_interactive_shell.patch.txt (3.4 KB)

TL;DR I can build little-lang with MSYS2 but I had to use --disable-shared.

MSYS2 Installation

Don’t mess with the default settings. It will be installed in C:\msys32 or
C:\msys64

  • initial setup (if you have not followed the MSYS2 installation instructions)

Follow these 3 steps to have an updated system. Restart MSYS2 if
necesary (C:\msys64\msys_shell.cmd).

Update pacman

> pacman -Sy pacman

Update msys2 runtime

> pacman -Syu

Update the rest with:

> pacman -Su

Build Little-lang

  • Install the packages for a build development environment.
    .

    pacman -S base-devel git vim wget mingw-w64-i686-toolchain mingw-w64-x86_64-toolchain

Now you can create 2 shortcuts for each toolchain. It’s important to use the
right parameter because it changes the path to the correct toolchain and
changes the output of “uname -a” (I think this is why in a previous post on
this thread georgn couldn’t build with msys2).

c:\msys64\msys_shell.cmd

> uname -a 
> MSYS_NT-10.0 Presario_CQ57 2.5.1(0.297/5/3) 2016-05-16 10:51 x86_64 Msys

c:\msys64\msys_shell.cmd -mingw32

> uname -a 
> MINGW32_NT-10.0 Presario_CQ57 2.5.1(0.297/5/3) 2016-05-16 10:51 x86_64 Msys

c:\msys64\msys_shell.cmd -mingw64

> uname -a 
> MINGW64_NT-10.0 Presario_CQ57 2.5.1(0.297/5/3) 2016-05-16 10:51 x86_64 Msys

There are two problems with the --enable-shared option:

– In 32 bit It builds and the executables run fine in the console but double clicking with the file manager in L-gui or L give an error.
– In 64 bit It can’t build with --enable-shared. There is a problem with zlib.
Looks like zlib is compiled in different way for gcc + win + 64 bit (tcl/win/configure.in:132)

> cd little-lang 
> patch -up1 -i ../MSYS2.patch.txt
> cd ..
  • Use the patch to fix the interactive shell in the terminal and the Tk console

The interactive shell is broken in all platforms. The #lang directive is not
processed by L-gui in the shell and the tk console and there is a bug in the L command
which stops evaluating code if a previous syntax error has been made.

> cd little-lang
> patch -up1 -i ../fix_interactive_shell.patch
> cd ..
  • Compiling little-lang

Don’t forget to start MSYS2 with the correct toolchain, for example “c:\msys64\msys_shell.cmd -mingw64”

Finally we can build little-lang

> cd little-lang
> make

The binaries are in L/opt/little-lang/bin

1 Like