[
https://issues.apache.org/jira/browse/STDCXX-109?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12510418
]
Andrew Black commented on STDCXX-109:
-------------------------------------
I am uncertain if this problem actually is a must fix for 4.2.0.
The OS and compiler in question are old, and we are at least able to get the
library to build on newer versions of the operating system (though other
problems have been observed). Combined with other problems with the
OS/compiler in question, I'm not certain it's worth trying to resolve the issue
- for this OS and compiler.
This issue points out a slightly larger problem though - Should we require
there to be a version of gencat on unix systems, or should we try to provide
some sort of a workaround for systems which lack the utility? If we chose the
former route, this issue can be closed as 'Won't Fix'. If the later, a
decision needs to be made on whether this accommodation is something that needs
to be done for 4.2.0.
--Andrew Black
> [Mac OS X 10.2.8] Unable to build rwstderr.cat (no gencat utility)
> ------------------------------------------------------------------
>
> Key: STDCXX-109
> URL: https://issues.apache.org/jira/browse/STDCXX-109
> Project: C++ Standard Library
> Issue Type: Bug
> Components: Build
> Environment: Mac OS X 10.2.8/Darwin 6.8 with GCC 3.1
> Reporter: Andrew Black
> Assignee: Andrew Black
> Fix For: 4.2
>
>
> When the make process gets to the point where it tries to build the
> rwstderr.cat file, the make process fails with
> gencat rwstderr.cat /Volumes/Orion/Work/stdcxx/src/rwstderr.msg
> /bin/sh: gencat: command not found
> make[2]: *** [rwstderr.cat] Error 127
> make[1]: *** [lib] Error 2
> make: *** [libstd] Error 2
> The most obvious cause is that there is no gencat utility installed on the
> system in the $PATH hierarchy. I have not searched for the gencat utility
> outside of the $PATH hierarchy at this point in time, though it would make
> sense to do so. As this utility is referenced as a part of the makefile
> rules, it would be difficult at best to control logic through the
> characterization tests.
> A possible way to detect if there is an accessable copy of gencat would be to
> use the which command, redirecting the output to /dev/null, and using the
> return code to detect the location.
> Another possible tactic would be to make the failed execution of gencat a non
> fatal problem (which likely would result in other problems if it failed in
> other circumstances), then to touch the output file when done so that a file
> is present (if empty) to be used in building the library.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
