[tlbuild] Compiling texk/dvisvgm/dvisvgm-1.2/src/dvisvgm/FileFinder.cpp under Solaris

[Apostolos Syropoulos]

2013/4/2 Karl Berry <karl at freefriends.org>

> Hi Apostolos,
>
>     [dvisvgm-1.2/src/FileFinder.cpp]
>     + #undef __cplusplus
>     + #define __cplusplus 1
>
> That change worked for me (not surprisingly), and I'm ok with it for the
> sake of moving on with TL'13 compilation, so I installed it.  It's
> certainly non-invasive.  However, it's not something I would expect the
> dvisvgm maintainer to want to install permamently since it's working
> around whatever the problem is by reverting to old behavior.
>
>
>
Hello again,

One reader of the OpenIndiana forum suggested the following patch:

      // unfortunately, the kpathsea headers are not C++-ready,
      // so we have to wrap it with some ugly code
+         #include <string.h>
      namespace KPS {
          extern "C" {
              #include <kpathsea/kpathsea.h>

With this patch the file compiles and I think that this one can applied
upstream.
Here is how the poster justified the patch:

*Because /usr/include/string.h has the normal #ifndef/#define wrapper on
it, changing the code as I describe above will cause this header file to
be included once in the proper context.  The second inclusion (buried
somewhere inside the expansion of kpathsea.h) will get dummied out by
the standard wrapper, and thus won't fall apart due to the weird KPS
context shifting going on here.

It's likely that this isn't the only header file that is affected, and
you may need a list of them.

Really, the right answer is to teach kpathsea.h how to be parsed by a
modern C++ compiler, and not to try to kludge around it in some other
random application with a brutal namespace hack.  It's 2013, right?*

After applying this patch, the Build process has successfully created 369
executables
for x86_64-pc-solaris2.11 and I expect no problem for i386-pc-solaris2.11

Best regards,

Apostolos

-- 
Apostolos Syropoulos
Xanthi, GREECE
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://tug.org/pipermail/tlbuild/attachments/20130402/fb17f653/attachment.html>