Bugzilla – Bug 838
ns-3 can't compile on MacOS with 32bit processor
Last modified: 2010-03-20 13:02:04 EDT
Ok, maybe it's my buggy laptop, but better be safe than sorry. I usually compile ns-3 on my quad-core 64bit machine, MacOS of course, and all goes fine. Now I needed to compile on my laptop, it went nuts. Machine: Model Name: MacBook Pro Model Identifier: MacBookPro2,2 Processor Name: Intel Core 2 Duo Processor Speed: 2,33 GHz Number Of Processors: 1 Total Number Of Cores: 2 The CPU is 32 bit. --- result of ./waf -v (stripped): 23:05:03 runner system command -> ['/usr/bin/gcc', '-arch', 'i386', '-O0', '-ggdb', '-g3', '-Wall', '-Werror', '-fPIC', '-compatibility_version', '1', '-current_version', '1', '-Idebug', '-I..', '-D_DEBUG', '-DNS3_ASSERT_ENABLE', '-DNS3_LOG_ENABLE', '-DNS3_MODULE_COMPILATION', '../src/simulator/cairo-wideint.c', '-c', '-o', 'debug/src/simulator/cairo-wideint_1.o'] [...] ld: warning: in debug/src/simulator/cairo-wideint_1.o, file is not of required architecture Undefined symbols: "__cairo_uint64x64_128_mul", referenced from: ns3::HighPrecision::Mul128(cairo_uint128, cairo_uint128)in high-precision-128_1.o ns3::HighPrecision::Mul128(cairo_uint128, cairo_uint128)in high-precision-128_1.o ns3::HighPrecision::Mul128(cairo_uint128, cairo_uint128)in high-precision-128_1.o ns3::HighPrecision::Mul128(cairo_uint128, cairo_uint128)in high-precision-128_1.o [...] Linking failed. Cairo has been installed my MacPorts, and it's version is 1.8.8. I could remove it but ghostscript (also installed by MacPorts is dependent on cairo. I'm pretty sure that some time ago ns-3 was compiling and running perfectly also on this crappy laptop. I need a confirmation that it's a real bug from another developer as the only way to find out if it's me or what would be to erase my OS and reinstall everything from scratch. However if it's a confirmed bug it must be solved as soon as possible.
Is this specific to ns-3-dev? Does ns-3.7 work?
Tommaso, I can't reproduce this on a Leopard powerpc g4: darwin-ppc:ns-3-dev nsnam$ hg log | head changeset: 6121:bd7f93a8ee33 tag: tip user: Josh Pelkey <jpelkey@gatech.edu> date: Wed Mar 10 14:45:06 2010 -0500 summary: revert scan, something went wrong Model Name: PowerBook G4 15" Model Identifier: PowerBook5,6 Processor Name: PowerPC G4 (1.2) Processor Speed: 1.5 GHz Number Of CPUs: 1 L2 Cache (per CPU): 512 KB System Version: Mac OS X 10.5.8 (9L31a) Kernel Version: Darwin 9.8.0 gcc version 4.0.1 (Apple Inc. build 5493)
I did some more tests, and I'm clueless tbh. It seems that waf is kinda overriding my architecture. Anyway. Machine A: Intel Core 2 Duo (32bit) Machine B: Quad-Core Intel Xeon (64bit) Both are running the very same OS (10.6.2) and same development tools (gcc 4.2.1). On both the command "arch" gives the same answer: "i386", as the Xeon is running a 32-bit kernel. Starting the "dumb's test", as is: "nm -go -arch i386 whatever.o" / "nm -go -arch x86_64 whatever.o" will tell me what architecture the .o has been compiled for. Machine B: all the .o tested are x86_64, no matter what the "arch" command said. Weird, but it works. It's a 64bit cpu anyway. Machine A: all the .o tested are x86_64 BUT ONE. cairo_wideint_1.o (it's the only one) is arch 386. Hence the error and the linker upset. Beat me in the head if I can understand what's going on. It's like if cairo_wideint had its own private compiler options, but it doesn't. I'm clueless, but the bug is confirmed here. By the way, ns-3.7 is just compiling fine. The bug is in the actual dev. At this point I'm wondering if it's affecting also 386-32 bit linux architectures as well.
I found the bug and I fixed it. No change in code is necessary, but a warning in the installation wiki is. Maybe there's a bug somewhere else in the build system tho. The issue was due to a stale "CFLAGS=-arch i386" in my .profile, left there from an old omnet installation. Kill it, reconfigure ns-3 and all goes smooth as butter. This is what have to be pointed out in the wiki. Now the "possible" build system bug. cairo-wideint.c was the ONLY source file using it. All the other files had a runner like: runner system command -> ['/usr/bin/gcc', '-O0', '-ggdb', '-g3', '-Wall', ... etc. while cairo_wident had it like runner system command -> ['/usr/bin/gcc', '-arch', 'i386', '-O0', '-ggdb', '-g3', '-Wall', ... etc. Hence the headaches. Cheers, Tommaso