Bugzilla – Bug 1174
Ns-3 does not generate static libraries
Last modified: 2011-09-18 19:13:43 UTC
The static libraries are very important if users want to link their program static with ns-3, and they are required by Debian Policy or requirement of some other distributions. For packaging to Debian, I patched ns-3 the attachment is my patch. It seems works well, except it can not install these static libraries. As I am not familiar with waf, sorry for this issues.
Created attachment 1151 [details] patch to make ns-3 generate static libraries.
Do you really need both static and dynamic libraries at the same time? Note that we can build static libraries in ns-3 via --enable-static configure option...
(In reply to comment #2) > Do you really need both static and dynamic libraries at the same time? Note > that we can build static libraries in ns-3 via --enable-static configure > option... The debian policy requires it. It takes several more disk space but not more build time. I think its worth to support it.
(In reply to comment #3) > (In reply to comment #2) > > Do you really need both static and dynamic libraries at the same time? Note > > that we can build static libraries in ns-3 via --enable-static configure > > option... > > The debian policy requires it. > It takes several more disk space but not more build time. > > I think its worth to support it. This needs more work: 1. Most users do not need both libraries at the same time, and are not prepared to pay the price (time) of building both. We need a configure option to enable this; 2. Too many changes all over the place, we need to find a way to make the static library built transparently without needing to change the modules' wscripts. Changes could be contained in the bld.create_ns3_module function. How exactly this can be done is not so clear right now, maybe we need a new special TaskGen which creates additional TaskGens for both types of libraries. This is tricky but worth it. I may be able to find some time to attempt this, but not so soon...
Created attachment 1177 [details] patch This patch adds a --enable-shared-and-static option, and allows building both shared and static at the same time but without changing the modules' wscripts. Also adds installation of the static libraries.
(In reply to comment #5) > Created attachment 1177 [details] > patch > > This patch adds a --enable-shared-and-static option, and allows building both > shared and static at the same time but without changing the modules' wscripts. > Also adds installation of the static libraries. The above patch needed more work. Committed a newer patch: changeset: 7331:827246e3bc4c tag: tip user: Gustavo J. A. M. Carneiro <gjc@inescporto.pt> date: Sun Jul 03 12:01:29 2011 +0100 summary: Bug 1174 - Ns-3 does not generate static libraries Now the method bld.create_ns3_module() creates a new ns3module_taskgen object, and this object will in turn create additional taskgens, one for shared library and another for static, if applicable.
It seems that it can not link into shared libraries. Didn't complied with -fPIC? [1708/1862] cxx_link: build/debug/src/core/model/unix-system-condition_57.o build/debug/src/core/model/time_3.o build/debug/src/core/model/event-id_4.o build/debug/src/core/model/scheduler_5.o build/debug/src/core/model/list-scheduler_6.o build/debug/src/core/model/map-scheduler_7.o build/debug/src/core/model/heap-scheduler_8.o build/debug/src/core/model/calendar-scheduler_9.o build/debug/src/core/model/ns2-calendar-scheduler_10.o build/debug/src/core/model/event-impl_11.o build/debug/src/core/model/simulator_12.o build/debug/src/core/model/simulator-impl_13.o build/debug/src/core/model/default-simulator-impl_14.o build/debug/src/core/model/timer_15.o build/debug/src/core/model/watchdog_16.o build/debug/src/core/model/synchronizer_17.o build/debug/src/core/model/make-event_18.o build/debug/src/core/model/log_19.o build/debug/src/core/model/breakpoint_20.o build/debug/src/core/model/type-id_21.o build/debug/src/core/model/attribute-construction-list_22.o build/debug/src/core/model/object-base_23.o build/debug/src/core/model/ref-count-base_24.o build/debug/src/core/model/object_25.o build/debug/src/core/model/test_26.o build/debug/src/core/model/random-variable_27.o build/debug/src/core/model/rng-stream_28.o build/debug/src/core/model/command-line_29.o build/debug/src/core/model/type-name_30.o build/debug/src/core/model/attribute_31.o build/debug/src/core/model/boolean_32.o build/debug/src/core/model/integer_33.o build/debug/src/core/model/uinteger_34.o build/debug/src/core/model/enum_35.o build/debug/src/core/model/double_36.o build/debug/src/core/model/int64x64_37.o build/debug/src/core/model/string_38.o build/debug/src/core/model/pointer_39.o build/debug/src/core/model/object-ptr-container_40.o build/debug/src/core/model/object-factory_41.o build/debug/src/core/model/global-value_42.o build/debug/src/core/model/trace-source-accessor_43.o build/debug/src/core/model/config_44.o build/debug/src/core/model/callback_45.o build/debug/src/core/model/names_46.o build/debug/src/core/model/vector_47.o build/debug/src/core/model/fatal-impl_48.o build/debug/src/core/model/system-path_49.o build/debug/src/core/model/unix-system-wall-clock-ms_50.o build/debug/src/core/model/int64x64-128_51.o build/debug/src/core/model/realtime-simulator-impl_52.o build/debug/src/core/model/wall-clock-synchronizer_53.o build/debug/src/core/model/unix-fd-reader_54.o build/debug/src/core/model/unix-system-thread_55.o build/debug/src/core/model/unix-system-mutex_56.o -> build/debug/libns3-core.so /usr/bin/ld.bfd.real: debug/src/core/model/time_3.o: relocation R_X86_64_32 against `typeinfo for ns3::TimeValue' can not be used when making a shared object; recompile with -fPIC debug/src/core/model/time_3.o: could not read symbols: Bad value collect2: ld returned 1 exit status
This used to work at some point, though I haven't tested lately.
I strongly suspect a waf bug; it compiles the same source file twice, correctly, with different object file names (e.g. time.cc produces time_3.o and time_58.o) but is linking the wrong object files for the wrong library type. If this is a waf bug, it means it will be far from trivial to fix. :-(
It's your fault. You define bld for every modules like def build(bld): # Don't do anything for this module if click should not be built. if 'click' in bld.env['MODULES_NOT_BUILT']: return module = bld.create_ns3_module('click', ['internet']) module.includes = '. CPPPATH_NSCLICK' module.source = [ 'model/ipv4-click-routing.cc', 'model/ipv4-l3-click-protocol.cc', 'helper/click-internet-stack-helper.cc', ] this is the only module, but you need 2 here. you should do it like: def build(bld): # Don't do anything for this module if click should not be built. if 'click' in bld.env['MODULES_NOT_BUILT']: return module = bld.create_ns3_module_shared('click', ['internet']) module.includes = '. CPPPATH_NSCLICK' module.source = [ 'model/ipv4-click-routing.cc', 'model/ipv4-l3-click-protocol.cc', 'helper/click-internet-stack-helper.cc', ] module_static = bld.create_ns3_module_static('click', ['internet']) module_static.includes = '. CPPPATH_NSCLICK' module_static.source = [ 'model/ipv4-click-routing.cc', 'model/ipv4-l3-click-protocol.cc', 'helper/click-internet-stack-helper.cc', ]
Python can return 2 value. may be you can do it: module1, module2 = create_ns3_module(...)
The --enable-shared-and-static option is being removed. YunQiang Su, please don't be mad :-) This is mainly a manpower issue: I just don't have time to maintain the extra complexity that such an option would cause, and it is just convenience for what can be achieved in another way.