On 2018/12/04 16:23, Brian Callahan wrote:
>
>
> On 12/4/18 4:11 PM, Charles A Daniels wrote:
> > > This version is much nicer.
> > I agree your version is more pleasing. I approve of using this.
> >
> > I'm still new around here and learning the conventions, so having this
> > to diff is very helpful for me.
> >
> > My interpretation of Mike's (the upstream) response was that pcalc-4
> > isn't known to work reliably on 32 bit systems right now, but I would
> > appreciate it if anyone with an i386 or other 32 bit arch could test to
> > make sure the issue (https://github.com/vapier/pcalc/issues/7) isn't
> > macppc specific. I'm happy to continue being the liaison to the
> > upstream as other arches or issues are discovered.
> >
> > I think it should be safe to ship pcalc-4 as it stands on AMD64, and
> > probably other 64 bit arches (I don't have any to test on though).
> >
> > Thanks for your help Brian!
> >
>
> Upstream says "32-bit systems are supported, i just don't actively test on
> them anymore, so problems like this might slip in."
>
> Since it is a tiny utility in C with only bison as a BDEP, I take that to
> mean "might as well build it everywhere and if users report that it's broken
> don't be afraid to mark it ONLY_FOR_ARCHS=${LP64_ARCHS} and bother upstream
> about fixing it," which it seems to be on the table anyway with a move to
> using GMP.
>
> ~Brian
>
pcalc.012 passes on i386 (i.e. little-endian 32-bit) with clang (default
compiler) or ports-gcc, but fails with base-gcc.
Based on this I would set
COMPILER = base-clang ports-gcc
COMPILER_LANGS = c
Please add CC="${CC}" to MAKE_FLAGS while there (the wrapper script
does handle it anyway, but it's nicer that way).
