Re: Issue 48 in google-ctemplate: Compile ctemplate with MinGW GCC 4.4.0

[codesite...@google.com]

Updates:
Labels: Type-Enhancement Priority-Medium

Comment #1 on issue 48 by csilvers: Compile ctemplate with MinGW GCC 4.4.0
http://code.google.com/p/google-ctemplate/issues/detail?id=48

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.

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

[codesite...@google.com]

Updates:
Status: Started

Comment #2 on issue 48 by csilvers: Compile ctemplate with MinGW GCC 4.4.0
http://code.google.com/p/google-ctemplate/issues/detail?id=48

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.

[codesite...@google.com]

Comment #3 on issue 48 by jonathan.brandmeyer: Compile ctemplate with MinGW
GCC 4.4.0
http://code.google.com/p/google-ctemplate/issues/detail?id=48

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.

[codesite...@google.com]

Comment #4 on issue 48 by csilvers: Compile ctemplate with MinGW GCC 4.4.0
http://code.google.com/p/google-ctemplate/issues/detail?id=48

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.

[codesite...@google.com]

Comment #5 on issue 48 by jonathan.brandmeyer: Compile ctemplate with MinGW
GCC 4.4.0
http://code.google.com/p/google-ctemplate/issues/detail?id=48

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.

Attachments:
errors.txt 76.9 KB

[codesite...@google.com]

Comment #6 on issue 48 by csilvers: Compile ctemplate with MinGW GCC 4.4.0
http://code.google.com/p/google-ctemplate/issues/detail?id=48

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.

[codesite...@google.com]

Updates:
Status: Fixed

Comment #7 on issue 48 by csilvers: Compile ctemplate with MinGW GCC 4.4.0
http://code.google.com/p/google-ctemplate/issues/detail?id=48

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

--
You received this message because you are listed in the owner
or CC fields of this issue, or because you starred this issue.
You may adjust your issue notification preferences at:
http://code.google.com/hosting/settings

--

You received this message because you are subscribed to the Google Groups "google-ctemplate" group.
To post to this group, send email to google-c...@googlegroups.com.
To unsubscribe from this group, send email to google-ctempla...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-ctemplate?hl=en.