Bugzilla – Bug 1224
Ns-3-allinone fails to compile on Lion
Last modified: 2011-08-07 11:53:41 EDT
Created attachment 1210 [details] Compilation log ns-3-dev works fine, but ns-3-allinone does not compile. The difference is on Python bindings, as -dev does not find pybindgen, thus it does not try to use Python bindings. I can't test if it works on Snow Leopard since I erased my previous installation. gcc is: i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2335.15.00) Copyright (C) 2007 Free Software Foundation, Inc. The logs are attached. Tommaso
Created attachment 1211 [details] Config log
I think this is due to llvm-gcc replacing plain old gcc in osx lion. http://useyourloaf.com/blog/2011/3/21/compiler-options-in-xcode-gcc-or-llvm.html PyBindGen uses interal APIs that llvm-gcc doesn't provide. I'm not sure how to fix this. But the bug is due to the new system, it doesn't sound like anything changed on ns-3 or pybindgen side.
(In reply to comment #2) > I think this is due to llvm-gcc replacing plain old gcc in osx lion. > > http://useyourloaf.com/blog/2011/3/21/compiler-options-in-xcode-gcc-or-llvm.html > > PyBindGen uses interal APIs that llvm-gcc doesn't provide. I'm not sure how to > fix this. But the bug is due to the new system, it doesn't sound like anything > changed on ns-3 or pybindgen side. If this is the case it can be "easily" tested by setting the compiler to gcc-4.2, as is the "plain old" gcc. The only problem is that i can't find a way to force was to use that particular compiler. It's too smart (or too dumb). I tried to set manually the CC and CXX environment variables, but the result is: Checking for program gcc or cc : gcc-4.2 Checking for program cpp : /usr/bin/cpp Checking for program ar : /usr/bin/ar Checking for program ranlib : /usr/bin/ranlib Checking for gcc : ok Checking for program g++ or c++ : g++-4.2 Checking for g++ : ok Checking for program pkg-config : /opt/local/bin/pkg-config cpp path is wrong, it's the llvm one. Any suggestion on how to force it ? I'd like to be able to hack the Makefile, but there's no Makefile. Cheers, Tommaso
(In reply to comment #3) > cpp path is wrong, it's the llvm one. > > Any suggestion on how to force it ? I'd like to be able to hack the Makefile, > but there's no Makefile. > In theory, you would set the CPP environment variable to the full file name of the cpp you'd like to use. CPP=/foo/bar/mycpp ./waf configure ...
Created attachment 1212 [details] Extremely verbose compile log
(In reply to comment #4) > (In reply to comment #3) > > cpp path is wrong, it's the llvm one. > > > > Any suggestion on how to force it ? I'd like to be able to hack the Makefile, > > but there's no Makefile. > > > > In theory, you would set the CPP environment variable to the full file name of > the cpp you'd like to use. > > CPP=/foo/bar/mycpp ./waf configure ... It worked. The forcing to use old gcc I mean... I was setting CC and CXX, forgot CC. Sadly it's not helping. The compiler is now the "plain old" gcc: i686-apple-darwin11-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3) Copyright (C) 2007 Free Software Foundation, Inc. On the other hand the extremely verbose compilation log could give more insights. There are some infinite recursions. I don't know if it's the intended behavior, but I suspect it isn't. Maybe the bug is related to this recursion. 3:04:18 preproc line is include - "ipv4-interface-container.h" state is ['a'] 23:04:18 preproc include found ipv4-interface-container.h (") 23:04:18 preproc line parsing failed (recursion limit exceeded): "ipv4-interface-container.h" Traceback (most recent call last): File "/Users/pecos/Development/workspace/ns-3-allinone/ns-3-dev/.waf-1.5.16-e6d03192b5ddfa5ef2c8d65308e48e42/wafadmin/Tools/preproc.py", line 504, in start self.process_line(kind,line) File "/Users/pecos/Development/workspace/ns-3-allinone/ns-3-dev/.waf-1.5.16-e6d03192b5ddfa5ef2c8d65308e48e42/wafadmin/Tools/preproc.py", line 537, in process_line self.tryfind(inc) File "/Users/pecos/Development/workspace/ns-3-allinone/ns-3-dev/.waf-1.5.16-e6d03192b5ddfa5ef2c8d65308e48e42/wafadmin/Tools/preproc.py", line 458, in tryfind self.addlines(found) File "/Users/pecos/Development/workspace/ns-3-allinone/ns-3-dev/.waf-1.5.16-e6d03192b5ddfa5ef2c8d65308e48e42/wafadmin/Tools/preproc.py", line 464, in addlines if self.count_files>recursion_limit:raise PreprocError("recursion limit exceeded") PreprocError: recursion limit exceeded
Nevermind the preproc recursions, the old error is still there, at the end. *sigh* once again Mac OS X has to be different, now even gcc is forked :( I need to figure out at compile time whether the compiler supports the full internal gcc abi::__si_class_type_info. Yes, I know it is marked internal, but it is useful... In file included from debug/src/network/bindings/ns3module.cc:1: debug/src/network/bindings/ns3module.h: In member function ‘PyTypeObject* pybindgen::TypeMap::lookup_wrapper(const std::type_info&, PyTypeObject*)’: debug/src/network/bindings/ns3module.h:262: error: expected initializer before ‘*’ token debug/src/network/bindings/ns3module.h:267: error: ‘_typeinfo’ was not declared in this scope debug/src/network/bindings/ns3module.h:268: error: ISO C++ forbids declaration of ‘type name’ with no type debug/src/network/bindings/ns3module.h:268: error: expected `>' debug/src/network/bindings/ns3module.h:268: error: expected `(' debug/src/network/bindings/ns3module.h:268: error: ‘__si_class_type_info’ is not a member of ‘abi’ debug/src/network/bindings/ns3module.h:268: error: expected primary-expression before ‘>’ token debug/src/network/bindings/ns3module.h:268: error: expected `)' before ‘;’ token Waf: Leaving directory `/Users/pecos/Development/workspace/ns-3-allinone/ns-3-dev/build' Build failed: -> task failed (err #1): {task: cxx module_helpers.cc -> module_helpers_6.o} -> task failed (err #1): {task: cxx ns3module.cc -> ns3module_4.o} -> task failed (err #1): {task: cxx ns3module.cc -> ns3module_6.o} -> task failed (err #1): {task: cxx ns3module.cc -> ns3module_5.o} File "./waf", line 158, in <module> Scripting.prepare(t, cwd, VERSION, wafdir) File "/Users/pecos/Development/workspace/ns-3-allinone/ns-3-dev/.waf-1.5.16-e6d03192b5ddfa5ef2c8d65308e48e42/wafadmin/Scripting.py", line 107, in prepare error(str(e))
This should fix it, in theory... changeset: 7408:4f1f961b6cdc tag: tip user: Gustavo J. A. M. Carneiro <gjc@inescporto.pt> date: Sun Aug 07 16:52:49 2011 +0100 summary: Bug 1224 - Ns-3-allinone fails to compile on Lion