# Problems compiling with --enable-int64
**URL:** https://community.zeek.org/t/problems-compiling-with-enable-int64/1317
**Category:** Zeek
**Created:** [April 15, 2008, 9:20pm UTC](https://community.zeek.org/t/problems-compiling-with-enable-int64/1317 "2008-04-15T21:20:00Z")
**Posts on this page:** 11
**Page:** 1
### Author:  [@Paul\_Schmehl](https://community.zeek.org/u/Paul_Schmehl)
#### Post date: [April 15, 2008, 9:20pm UTC](https://community.zeek.org/t/problems-compiling-with-enable-int64/1317/1 "2008-04-15T21:20:00Z")
I'm working on updating the FreeBSD port of bro (I'm the port maintainer), and I've been testing various combinations of options. I've run into a problem compiling with --enable-int64.
Val.cc: In member function 'virtual Val\* Val::SizeVal() const':
Val.cc:567: error: call of overloaded 'abs(const bro\_int\_t&)' is ambiguous
/usr/include/stdlib.h:84: note: candidates are: int abs(int)
/usr/include/c++/4.2/cstdlib:143: note: long int std::abs(long int)
\*\*\* Error code 1
Is this a bug in the code? Or do I need to point to a library that's not found? Configure works fine, but make fails.
Compiler is gcc 4.2.1. OS version is 7.0 STABLE.
---
### Author:  [@Vern](https://community.zeek.org/u/Vern)
#### Post date: [April 15, 2008, 10:11pm UTC](https://community.zeek.org/t/problems-compiling-with-enable-int64/1317/2 "2008-04-15T22:11:48Z")
> Val.cc: In member function 'virtual Val\* Val::SizeVal() const':
> Val.cc:567: error: call of overloaded 'abs(const bro\_int\_t&)' is ambiguous
I'm guessing that the line you're looking at is
return new Val(abs(val.int\_val), TYPE\_COUNT);
(it's at a different location in the latest snapshot). If so, try
return new Val(bro\_int\_t(abs(val.int\_val)), TYPE\_COUNT);
and see if that fixes the problem.
Vern
---
### Author:  [@Paul\_Schmehl](https://community.zeek.org/u/Paul_Schmehl)
#### Post date: [April 15, 2008, 10:42pm UTC](https://community.zeek.org/t/problems-compiling-with-enable-int64/1317/3 "2008-04-15T22:42:51Z")
That did not fix the problem.
Val.cc: In member function 'virtual Val\* Val::SizeVal() const':
Val.cc:567: error: call of overloaded 'abs(const bro\_int\_t&)' is ambiguous
/usr/include/stdlib.h:84: note: candidates are: int abs(int)
/usr/include/c++/4.2/cstdlib:143: note: long int std::abs(long int)
---
### Author:  [@Vern](https://community.zeek.org/u/Vern)
#### Post date: [April 15, 2008, 11:02pm UTC](https://community.zeek.org/t/problems-compiling-with-enable-int64/1317/4 "2008-04-15T23:02:14Z")
> That did not fix the problem.
Rats. Well, this doesn't repreoduce for me (w/ g++ 4.0.1), so I'm reduced
to guessing. The next thing I'd try is
return new Val(abs(bro\_int\_t(val.int\_val)), TYPE\_COUNT);
but if that doesn't work, I'm not sure what next to try.
Vern
---
### Author:  [@Paul\_Schmehl](https://community.zeek.org/u/Paul_Schmehl)
#### Post date: [April 16, 2008, 1:30am UTC](https://community.zeek.org/t/problems-compiling-with-enable-int64/1317/5 "2008-04-16T01:30:27Z")
Sadly, that did not work either. I'm afraid I'm not a programmer, so all I can do is follow your lead. For now I'll make that option is non-working and continue working on the update to the port.
If anyone on the list has the same version of gcc and can test this and find a resolution, please post it to the list. I'll include a patch in the port to fix it.
Paul Schmehl (pauls@utdallas.edu)
Senior Information Security Analyst
The University of Texas at Dallas
[http://www.utdallas.edu/ir/security/](http://www.utdallas.edu/ir/security/)
---
### Author:  [@Joel\_Ebrahimi1](https://community.zeek.org/u/Joel_Ebrahimi1)
#### Post date: [April 16, 2008, 1:54am UTC](https://community.zeek.org/t/problems-compiling-with-enable-int64/1317/6 "2008-04-16T01:54:44Z")
When compiling with the --enable-int64 flag, the variable val.int\_val is a ‘long long int’. It appears the abs function on your system is defined for ‘int’ and ‘long int’. You could probalby typecast the variable so that the compiler uses the ‘long int’ version. Though depending of the size of ‘long int’ on your system this could have an undesired effect. If ‘long int’ on your system is 64bits wide though you should be ok.
You can try:
return new Val(abs((long int)val.int\_val), TYPE\_COUNT);
The other concern here is that this is a one function fix and your going to run into this issue everytime you pass a ‘long long int’ to a function that has defines for just ‘int’ and ‘long int’.
If ‘long int’ is 64bits wide on your system, you might be better off editing the bro header file util.h so that you redefine int64.
typedef long long int int64;
would become
typedef long int int64;
// Joel
---
### Author:  [@Paul\_Schmehl](https://community.zeek.org/u/Paul_Schmehl)
#### Post date: [April 16, 2008, 2:07am UTC](https://community.zeek.org/t/problems-compiling-with-enable-int64/1317/7 "2008-04-16T02:07:28Z")
Thanks, Joel. This seems to point to a bigger problem. This software could be installed on any FreeBSD system, from an older OS to a brand new one, from i386 to amd to solaris. So, it's seems this is a situation that would call for an #ifdef, would it not?
I don't know the size of a long int on my system, but I'm almost certain that it won't be the same on \*every\* system.
Paul Schmehl (pauls@utdallas.edu)
Senior Information Security Analyst
The University of Texas at Dallas
[http://www.utdallas.edu/ir/security/](http://www.utdallas.edu/ir/security/)
---
### Author:  [@Paul\_Schmehl](https://community.zeek.org/u/Paul_Schmehl)
#### Post date: [April 16, 2008, 2:42am UTC](https://community.zeek.org/t/problems-compiling-with-enable-int64/1317/8 "2008-04-16T02:42:33Z")
Here's what I have in my includes:
/usr/src/sys/i386/include/\_types.h:typedef long long \_\_int64\_t;
/usr/src/sys/i386/include/\_types.h:typedef unsigned long long \_\_uint64\_t;
/usr/src/sys/i386/include/\_types.h:typedef long long \_\_int64\_t;
/usr/src/sys/i386/include/\_types.h:typedef unsigned long long \_\_uint64\_t;
Fixing the function per your instructions allows the software to make successfully. I'm concerned, however, about your second point. If I change the define in util.h, will it break on some FreeBSD systems? I don't know.
According to the cvs repository, \_inttypes.h hasn't been changed in almost six years on i386.
\<[http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/include/\_inttypes.h](http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/i386/include/_inttypes.h)\>
It's been almost 5 years on amd64 and 5 years on ia64.
I guess I'm alright to redefine in util.h.
Paul Schmehl (pauls@utdallas.edu)
Senior Information Security Analyst
The University of Texas at Dallas
[http://www.utdallas.edu/ir/security/](http://www.utdallas.edu/ir/security/)
---
### Author:  [@Paul\_Schmehl](https://community.zeek.org/u/Paul_Schmehl)
#### Post date: [April 16, 2008, 2:59am UTC](https://community.zeek.org/t/problems-compiling-with-enable-int64/1317/9 "2008-04-16T02:59:12Z")
That didn't work. I'll have to patch Val.cc.
Paul Schmehl (pauls@utdallas.edu)
Senior Information Security Analyst
The University of Texas at Dallas
[http://www.utdallas.edu/ir/security/](http://www.utdallas.edu/ir/security/)
---
### Author:  [@Joel\_Ebrahimi1](https://community.zeek.org/u/Joel_Ebrahimi1)
#### Post date: [April 16, 2008, 3:10am UTC](https://community.zeek.org/t/problems-compiling-with-enable-int64/1317/10 "2008-04-16T03:10:04Z")
I didnt think about the port aspect(not much experience).
Definately not the way to maintain a build of somethign that would work across all OS’s
And in most cases there probably be a difference in bytes (4 vs 8) on most OS’s anyways.
An #ifdef would be the way to go, but my said typecasting would not be good for a port.
Looks like there are different functions for calculating absolute zero on different OS’s.
Check your headers for llabs.
This might be the way to go for portability
try swapping:
return new Val(abs(val.int\_val), TYPE\_COUNT);
for:
#ifdef USE\_INT64
return new Val(llabs(val.int\_val), TYPE\_COUNT);
#else
return new Val(abs(val.int\_val), TYPE\_COUNT);
#endif
It may be better to define this function in a header but you can see if this works.
// Joel
---
### Author:  [@system](https://community.zeek.org/u/system)
#### Post date: [May 6, 2022, 3:38pm UTC](https://community.zeek.org/t/problems-compiling-with-enable-int64/1317/11 "2022-05-06T15:38:31Z")