Bug#840461: openfoam: FTBFS (32-bit): ambiguous overload for 'operator<<'

2016-10-11 Thread Anton Gladky
Hi Aaron,

thanks for the notice and the tip! OpenFOAM has just entered an
archive and I will try to fix FTBFSs on 32-bit platforms.

Regards

Anton


2016-10-11 20:25 GMT+02:00 Aaron M. Ucko :
>   db/dictionary/functionEntries/codeStream/codeStream.C:200:44: error: 
> ambiguous overload for 'operator<<' (operand types are 'Foam::Ostream' and 
> 'off_t {aka long int}')
>
> The problem is that, on these architectures, off_t is formally long
> whereas int32_t (for which an operator<< variant exists) is formally
> int; although the types are de facto equivalent on these
> architectures, C++ insists on treating them as distinct.
>
> I would suggest adding explicit long and unsigned long variants on
> these architectures (but not 64-bit architectures, on which they'll
> duplicate the existing [u]int64_t variants.)

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers


Bug#840461: openfoam: FTBFS (32-bit): ambiguous overload for 'operator<<'

2016-10-11 Thread Aaron M. Ucko
Source: openfoam
Version: 4.0+dfsg1-3
Severity: important
Justification: fails to build from source

Builds of openfoam for 32-bit architectures have been failing:

  db/dictionary/functionEntries/codeStream/codeStream.C: In static member 
function 'static void (* Foam::functionEntries::codeStream::getFunction(const 
Foam::dictionary&, const Foam::dictionary&))(Foam::Ostream&, const 
Foam::dictionary&)':
  db/dictionary/functionEntries/codeStream/codeStream.C:200:44: error: 
ambiguous overload for 'operator<<' (operand types are 'Foam::Ostream' and 
'off_t {aka long int}')

The problem is that, on these architectures, off_t is formally long
whereas int32_t (for which an operator<< variant exists) is formally
int; although the types are de facto equivalent on these
architectures, C++ insists on treating them as distinct.

I would suggest adding explicit long and unsigned long variants on
these architectures (but not 64-bit architectures, on which they'll
duplicate the existing [u]int64_t variants.)

Could you please take a look?

Thanks!

-- 
Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org)
http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu

-- 
debian-science-maintainers mailing list
debian-science-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/debian-science-maintainers