Compile ctemplate with MinGW GCC 4.4.0

[olafvdspek]

Compile ctemplate with MinGW GCC 4.4.0

[GoogleCodeExporter]

Wow, that's impressive work!  I don't know what libsupc++, and how much of what 
you
did was needed for shared libgcc (is shared libgcc normal in msys-land?) vs how 
much
is just ctemplate not supporting mingw, but there's definitely some of the 
latter,
which I'll try to fix up in the next release.  It shouldn't be that hard.

It's not clear to me which script test was breaking for you -- the project has
several.  What's the actual error/failure message that you got?

If it's in make_tpl_varnames_h_unittest, then the data lives in
/tmp/make_tpl_varnames_h_unittest_sh_dir.

Original comment by [email protected] on 24 Nov 2009 at 10:24

• Added labels: Type-Enhancement, Priority-Medium

[GoogleCodeExporter]

I set to work today getting ctemplate to work under mingw.  It's just about done
(though against a much older mingw, it looks like, that's running gcc 
3.something). 
I had to make a whole bunch of changes, which I'll get reviewed after 
thanksgiving,
most likely, and then submit to the SVN repository.

Original comment by [email protected] on 25 Nov 2009 at 2:12

• Changed state: Started

[GoogleCodeExporter]

Older MinGW did not provide either libgcc or libstdc++ as a shared library and 
they
forced the use of SJLJ EH.  MinGW GCC 4.4 is the first version to support 
libstdc++
as a shared library and also supports DWARF2 EH.  I personally greatly prefer 
to use
the latter, since it makes smaller executables and improves performance over 
SJLJ EH.

libsupc++ is normally linked in by default when linking with G++.  It is the 
GCC C++
support library.  However, you run into symbol collisions if you try to link 
with
libstdc++.dll and libstdc++.a at the same time, so you have to link with GCC and
explicitly provide the right libraries.

The script failure was in a state machine generation test.  The error spat out 
two
identical looking pieces of C source code and then claimed that they didn't 
match.  I
suspect that this is because of a line ending difference.  If one of the 
examples was
produced with an Msys utility, and another was produced by a native Windows 
program,
then they might have different line endings.  Alternatively, if the reference 
input
is provided in the tarball, then the line endings in the tarball would mostly 
likely
be Unix-style instead of Windows-style.

The intent is not to actually use libctemplate under Msys - I only use Msys to 
run
configure.  The intent is to build a Windows native DLL for writing native 
windows
programs using MinGW's port of GCC.

Thanks for your help.

Original comment by [email protected] on 27 Nov 2009 at 4:22

[GoogleCodeExporter]

I'm not sure I understand your last paragraph (well, not "thanks for your 
help," but
the one before that), but if you're running the unittests under mingw, then you 
are
using libctemplate under msys, so we'll have to get that working right.

I'm still not sure what test is failing.  If you can attach the complete output 
of
your test run, that would be helpful.  We can test your theory that the problem 
is
with line endings, and if so, figure out the right fix.

Original comment by [email protected] on 30 Nov 2009 at 6:44

[GoogleCodeExporter]

The difference is that libctemplate was not linked against msys-1.0.dll, so 
that it
is a native Windows DLL that uses the standard MSVC runtime library and not the 
MSYS
runtime library.  I have attached the console output of running 
$ PATH=/c/Python26:$PATH make check &> errors.txt

When I view this file using MSYS vi, the actual output contains extra line 
ending
characters, displayed as ^M, when compared to the expected output.

Original comment by [email protected] on 1 Dec 2009 at 2:46

Attachments:

• errors.txt

[GoogleCodeExporter]

Gotcha.  OK, I've modified the generator test to strip windows newlines before 
doing
the diff.  I'll check that into the SVN repository shortly, after it goes 
through the
review process here.

Original comment by [email protected] on 1 Dec 2009 at 8:36

[GoogleCodeExporter]

OK, ctemplate should compile under mingw with ctemplate 0.97, just released.

Original comment by [email protected] on 20 Apr 2010 at 5:54

• Changed state: Fixed