# Compile errors
**URL:** https://community.zeek.org/t/compile-errors/1817
**Category:** Development
**Tags:** development
**Created:** [February 16, 2011, 8:44pm UTC](https://community.zeek.org/t/compile-errors/1817 "2011-02-16T20:44:20Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@Don\_Appleman](https://community.zeek.org/u/Don_Appleman)
#### Post date: [February 16, 2011, 8:44pm UTC](https://community.zeek.org/t/compile-errors/1817/1 "2011-02-16T20:44:20Z")
I'm currently working to get automated builds going on the NMI build/test lab.
I have all the necessary prerequisites to build bro on the NMI x86\_64\_ubuntu\_10.04 platform, which is the same platform as my laptop. I can build without error on my laptop, but I get compile errors when building on the NMI build target.
Can someone give me an idea of how to resolve the following errors?
> In file included from /home/condor/execute/dir\_4281/userdir/bro/src/Conn.h:11,
> from /home/condor/execute/dir\_4281/userdir/bro/src/Analyzer.h:11,
> from /home/condor/execute/dir\_4281/userdir/bro/src/binpac\_bro.h:11,
> from /home/condor/execute/dir\_4281/userdir/bro/build/src/bittorrent\_pac.h:11,
> from /home/condor/execute/dir\_4281/userdir/bro/build/src/bittorrent\_pac.cc:3:
> /home/condor/execute/dir\_4281/userdir/bro/src/Val.h:130: error: 'Val::Val(int64, TypeTag)' cannot be overloaded
> /home/condor/execute/dir\_4281/userdir/bro/src/Val.h:100: error: with 'Val::Val(long int, TypeTag)'
> /home/condor/execute/dir\_4281/userdir/bro/src/Val.h:140: error: 'Val::Val(uint64, TypeTag)' cannot be overloaded
> /home/condor/execute/dir\_4281/userdir/bro/src/Val.h:120: error: with 'Val::Val(long unsigned int, TypeTag)'
Thanks much,
Don
---
### Author:  [@Jonathan\_Siwek](https://community.zeek.org/u/Jonathan_Siwek)
#### Post date: [February 16, 2011, 9:27pm UTC](https://community.zeek.org/t/compile-errors/1817/2 "2011-02-16T21:27:35Z")
> Can someone give me an idea of how to resolve the following errors?
>
> \> In file included from
> \> /home/condor/execute/dir\_4281/userdir/bro/src/Conn.h:11,
> \> from
> \> /home/condor/execute/dir\_4281/userdir/bro/src/Analyzer.h:11,
> \> from
> \> /home/condor/execute/dir\_4281/userdir/bro/src/binpac\_bro.h:11,
> \> from
> \> /home/condor/execute/dir\_4281/userdir/bro/build/src/bittorrent\_pac.h:11,
> \> from
> \> /home/condor/execute/dir\_4281/userdir/bro/build/src/bittorrent\_pac.cc:3:
> \> /home/condor/execute/dir\_4281/userdir/bro/src/Val.h:130: error:
> \> 'Val::Val(int64, TypeTag)' cannot be overloaded
> \> /home/condor/execute/dir\_4281/userdir/bro/src/Val.h:100: error: with
> \> 'Val::Val(long int, TypeTag)'
> \> /home/condor/execute/dir\_4281/userdir/bro/src/Val.h:140: error:
> \> 'Val::Val(uint64, TypeTag)' cannot be overloaded
> \> /home/condor/execute/dir\_4281/userdir/bro/src/Val.h:120: error: with
> \> 'Val::Val(long unsigned int, TypeTag)'
I don't have a resolution, but can suggest what to look at to (maybe) figure one out or at least better define what the problem is.
int64 looks like it's typedef'd in src/util.h depending on the definition of SIZEOF\_LONG\_LONG and SIZEOF\_LONG\_INT, which are both determined at configure time by cmake/CheckTypes.cmake and the result gets put in build/config.h.
So you can check the differences in the config.h's that get generated, but I think it looks like you'd always get this error if SIZEOF\_LONG\_LONG != 8 and SIZEOF\_LONG\_INT == 8, causing two declarations of the Val(long int, TypeTag) constructor. Either the Val constructors or the logic for typedef'ing int64 probably need to be revised.
- Jon
---
### Author:  [@robin](https://community.zeek.org/u/robin)
#### Post date: [February 16, 2011, 9:41pm UTC](https://community.zeek.org/t/compile-errors/1817/3 "2011-02-16T21:41:25Z")
Is this with current master? I fixed some defintions for the
int64-related typedefs a while ago in there. (If it's really exactly
the same platform, that shouldn't make a difference between NMI and
your laptop, but who knows).
Robin
---
### Author:  [@Don\_Appleman](https://community.zeek.org/u/Don_Appleman)
#### Post date: [February 16, 2011, 10:34pm UTC](https://community.zeek.org/t/compile-errors/1817/4 "2011-02-16T22:34:05Z")
Thanks for the helpful suggestions. I first compared the two versions of build/config.h and found that the defined sizes of the various types match. However, I also noticed that the version numbers were out of sync.
The NMI build always does a "git pull" prior to the build, and was completely up to date; the source on my laptop was out of date. Now that I've updated my laptop to the latest master (in a new directory I ran "git clone --recursive git://git.icir.org/bro"), I get the same compile errors on my laptop.
Any further guidance in addressing these compile errors is much appreciated. The remaining differences between the two builds are that the NMI version does not yet include libMagic or libGeoIP.
Thanks again,
Don
---
### Author:  [@robin](https://community.zeek.org/u/robin)
#### Post date: [February 16, 2011, 11:55pm UTC](https://community.zeek.org/t/compile-errors/1817/5 "2011-02-16T23:55:13Z")
> The NMI build always does a "git pull" prior to the build, and was
> completely up to date; the source on my laptop was out of date.
Interesting, seems I may have broken something then while I was fixing
the problem I had. I tried it on 32-bit and 64-bit FreeBSD, and 32-bit
Linux, but I think not on 64-bit Linux ... Well, I guess that's what
NMI build testing is for, right? 🙂
So back to the error messages:
\> /home/condor/execute/dir\_4281/userdir/bro/src/Val.h:130: error: 'Val::Val(int64, TypeTag)' cannot be overloaded
\> /home/condor/execute/dir\_4281/userdir/bro/src/Val.h:100: error: with 'Val::Val(long int, TypeTag)'
\> /home/condor/execute/dir\_4281/userdir/bro/src/Val.h:140: error: 'Val::Val(uint64, TypeTag)' cannot be overloaded
\> /home/condor/execute/dir\_4281/userdir/bro/src/Val.h:120: error: with 'Val::Val(long unsigned int, TypeTag)'
So this seems like there are "long unsigned int" and "long int"
versions of that method missing. If you can't figure it out, I'll try
it on comparable box but probably not today anymore.
Oh, which gcc version is this?
Robin
---
### Author:  [@Don\_Appleman](https://community.zeek.org/u/Don_Appleman)
#### Post date: [February 17, 2011, 12:31am UTC](https://community.zeek.org/t/compile-errors/1817/6 "2011-02-17T00:31:50Z")
This was on gcc 4.3.3. I'll have a longer look at it shortly.
Thanks, Robin,
Don
---
### Author:  [@Gregor\_Maier](https://community.zeek.org/u/Gregor_Maier)
#### Post date: [February 17, 2011, 1:38am UTC](https://community.zeek.org/t/compile-errors/1817/7 "2011-02-17T01:38:28Z")
this is an issue on 64bit machines.
My pending merge-request in #391 (topic/gregor/fix-val-64bit) fixes the
problem.
cu
gregor
---
### Author:  [@robin](https://community.zeek.org/u/robin)
#### Post date: [February 17, 2011, 5:41pm UTC](https://community.zeek.org/t/compile-errors/1817/8 "2011-02-17T17:41:19Z")
Perfect. I'll aim to merge that in soon. Don, in the meantime, you can
just merge this into devel for testing.
Robin
---
### Author:  [@Don\_Appleman](https://community.zeek.org/u/Don_Appleman)
#### Post date: [February 18, 2011, 8:34pm UTC](https://community.zeek.org/t/compile-errors/1817/9 "2011-02-18T20:34:34Z")
Thanks, Gregor -- your fix solves the compile errors I was getting. I guess you have this working on some 64-bit platform? I've encountered new compile errors further along in the build process ...
> Linking CXX shared module \_SubnetTree.so
> /usr/bin/ld: /prereq/Python-2.6.2/lib/libpython2.6.a(abstract.o): relocation R\_X86\_64\_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
> /prereq/Python-2.6.2/lib/libpython2.6.a: could not read symbols: Bad value
> collect2: ld returned 1 exit status
> make[2]: \*\*\* [aux/broctl/aux/pysubnettree/\_SubnetTree.so] Error 1
> make[1]: \*\*\* [aux/broctl/aux/pysubnettree/CMakeFiles/\_SubnetTree.dir/all] Error 2
> make: \*\*\* [all] Error 2
... which I suspect may also be a 64-bit platform problem. Do you have any guidance to offer on this new error? The Python-2.6.2 that I am using is the only version of python I have available on this particular build target.
Thanks again,
Don
---
### Author:  [@Gregor\_Maier](https://community.zeek.org/u/Gregor_Maier)
#### Post date: [February 18, 2011, 8:45pm UTC](https://community.zeek.org/t/compile-errors/1817/10 "2011-02-18T20:45:17Z")
> Thanks, Gregor -- your fix solves the compile errors I was getting. I guess you have this working on some 64-bit platform? I've encountered new compile errors further along in the build process ...
I do. It' some Fedora.
> > Linking CXX shared module \_SubnetTree.so
> > /usr/bin/ld: /prereq/Python-2.6.2/lib/libpython2.6.a(abstract.o): relocation R\_X86\_64\_32 against `.rodata.str1.8' can not be used when making a shared object; recompile with -fPIC
> > /prereq/Python-2.6.2/lib/libpython2.6.a: could not read symbols: Bad value
> > collect2: ld returned 1 exit status
> > make[2]: \*\*\* [aux/broctl/aux/pysubnettree/\_SubnetTree.so] Error 1
> > make[1]: \*\*\* [aux/broctl/aux/pysubnettree/CMakeFiles/\_SubnetTree.dir/all] Error 2
> > make: \*\*\* [all] Error 2
>
> ... which I suspect may also be a 64-bit platform problem. Do you have any guidance to offer on this new error? The Python-2.6.2 that I am using is the only version of python I have available on this particular build target.
I sometime have weird problems compiling some of the python modules but
I haven't really debugged it. What seems to work for me is:
\* remove build directory and do another ./configure
\* do a git submodule update --recursive
\* do a fresh recursive clone of the bro repository
hth
Gregor
---
### Author:  [@Jonathan\_Siwek](https://community.zeek.org/u/Jonathan_Siwek)
#### Post date: [February 18, 2011, 9:05pm UTC](https://community.zeek.org/t/compile-errors/1817/11 "2011-02-18T21:05:33Z")
> \> Linking CXX shared module \_SubnetTree.so
> \> /usr/bin/ld: /prereq/Python-2.6.2/lib/libpython2.6.a(abstract.o):
> \> relocation R\_X86\_64\_32 against `.rodata.str1.8' can not be used when
> \> making a shared object; recompile with -fPIC
There's a few different cases where you can get an error like this, but I think the situation you're in is that you're building a shared library on an AMD64 architecture which are required to be PIC-enabled, but you're linking to a static archive which was not built with the -fPIC flag.
> The Python-2.6.2 that I am using is the only version of python I have available on this particular build target.
Here's what I would probably do:
1) Search around a bit to make sure there really isn't a libpython2.6.so (shared library version) that you can link against
2) Inquire with NMI support about whether libpython2.6.a is indeed built wrong (without the -fPIC flag) and ask if they can fix it if it is
3) Do your own build of Python and compile Bro against that
- Jon
---
### Author:  [@system](https://community.zeek.org/u/system)
#### Post date: [May 6, 2022, 3:39pm UTC](https://community.zeek.org/t/compile-errors/1817/12 "2022-05-06T15:39:27Z")