Compile errors

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

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

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

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

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? :slight_smile:

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

This was on gcc 4.3.3. I'll have a longer look at it shortly.

Thanks, Robin,
Don

this is an issue on 64bit machines.

My pending merge-request in #391 (topic/gregor/fix-val-64bit) fixes the
problem.

cu
gregor

Perfect. I'll aim to merge that in soon. Don, in the meantime, you can
just merge this into devel for testing.

Robin

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

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

> 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