Bug 1230 - -Idebug command-line argument munged on darwin
-Idebug command-line argument munged on darwin
Status: RESOLVED FIXED
Product: ns-3
Classification: Unclassified
Component: build system
ns-3-dev
Mac Intel Mac OS
: P5 blocker
Assigned To: Mathieu Lacage
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-01 16:58 UTC by Mitch Watrous
Modified: 2011-08-02 08:08 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Mitch Watrous 2011-08-01 16:58:26 UTC
Only ns-3 header files without "ns3/" in the paths for their included files will compile on darwin, which is a mac.

For example, 

    src/core/model/unix-system-condition.cc 

compiles because it has these includes:

    #include "fatal-error.h"
    #include "system-condition.h"
    #include "log.h"

But, 

    src/core/model/time.cc 

does not compiles because it has these includes

    #include "nstime.h"
    #include "ns3/abort.h"
    #include "ns3/global-value.h"
    #include "ns3/enum.h"
    #include "ns3/string.h"
    #include "ns3/object.h"
    #include "ns3/config.h"

and the first file it includes

    src/core/model/nstime.h

has these includes

    #include "ns3/assert.h"
    #include "ns3/attribute.h"
    #include "ns3/attribute-helper.h"
    #include "ns3/int64x64.h"

which causes these errors:

[ 603/1633] cxx: src/core/model/time.cc -> build/debug/src/core/model/time_3.o
In file included from ../src/core/model/time.cc:22:
../src/core/model/nstime.h:23:24: error: ns3/assert.h: No such file or directory
../src/core/model/nstime.h:24:27: error: ns3/attribute.h: No such file or directory
../src/core/model/nstime.h:25:34: error: ns3/attribute-helper.h: No such file or directory
../src/core/model/nstime.h:26:26: error: ns3/int64x64.h: No such file or directory
../src/core/model/time.cc:23:23: error: ns3/abort.h: No such file or directory
../src/core/model/time.cc:24:30: error: ns3/global-value.h: No such file or directory
../src/core/model/time.cc:25:22: error: ns3/enum.h: No such file or directory
../src/core/model/time.cc:26:24: error: ns3/string.h: No such file or directory
../src/core/model/time.cc:27:24: error: ns3/object.h: No such file or directory
../src/core/model/time.cc:28:24: error: ns3/config.h: No such file or directory

.
.
.
Comment 1 Mitch Watrous 2011-08-01 17:50:41 UTC
The following version of ns-3-dev worked on darwin:

Remove accidental scratch code insertion/commit
author	Gustavo J. A. M. Carneiro <gjc@inescporto.pt>
	Wed Jul 27 10:51:39 2011 +0100 (5 days ago)
changeset 7378	0f4ffed3cefc
parent 7377 	da629dd2fb11
child 7379
Comment 2 Mitch Watrous 2011-08-01 18:07:05 UTC
The following version of ns-3-dev did not work on darwin:

add support for --update-data to test.py, move test runner code to library for modular build, add support for hierarchical tests beyond the previous two-level hierarchy.
author	Mathieu Lacage <mathieu.lacage@gmail.com>
	Fri Jul 29 03:38:59 2011 -0400 (3 days ago)
changeset 7379	ff0d074f885a
parent 7378 	0f4ffed3cefc
child 7380 	197e25cb6a89

Because the version before it worked, this changeset was the cause.
Comment 3 Mathieu Lacage 2011-08-02 05:29:24 UTC
The problem comes from the following command-line that is generated by waf:

/usr/bin/g++ -O0 -ggdb -g3 -Wall -Werror -Wno-error=deprecated-declarations -fstrict-aliasing -Wstrict-aliasing -fPIC -compatibility_version 1 -current_version -Idebug -I.. -DNS_TEST_SOURCEDIR=src/core/model -D_DEBUG -DNS3_ASSERT_ENABLE -DNS3_LOG_ENABLE ../src/core/model/event-id.cc -c -o debug/src/core/model/event-id_4.o

i.e., if you remove the undocumented -current_version and -compatibility_version 1 options, the build works.

Note that these options are apple/osx-specific options added by waf. I could not find any documentation about them in the osx gcc manual.
Comment 4 Mathieu Lacage 2011-08-02 05:35:33 UTC
These are actually linker options: I suspect the osx engineers are too lazy to use -Wl :/

     -compatibility_version number
                 Specifies the compatibility version number of the library.  When a library is loaded by dyld, the compati-
                 bility version is checked and if the program's version is greater that the library's version, it is an
                 error.  The format of number is X[.Y[.Z]] where X must be a positive non-zero number less than or equal to
                 65535, and .Y and .Z are optional and if present must be non-negative numbers less than or equal to 255.
                 If the compatibility version number is not specified, it has a value of 0 and no checking is done when the
                 library is used.  This option is also called -dylib_compatibility_version for compatibility.

     -current_version number
                 Specifies the current version number of the library. The current version of the library can be obtained
                 programmatically by the user of the library so it can determine exactly which version of the library it is
                 using.  The format of number is X[.Y[.Z]] where X must be a positive non-zero number less than or equal to
                 65535, and .Y and .Z are optional and if present must be non-negative numbers less than or equal to 255.
                 If the version number is not specified, it has a value of 0.  This option is also called -dylib_cur-
                 rent_version for compatibility.
Comment 5 Mathieu Lacage 2011-08-02 05:40:10 UTC
which means that all that is missing for the command-line to work is a number after -current_version: what is going on here is that the -Idebug is swallowed by the linker to produce a version number. Why on earth did they not use -Wl to mark these stupid options. Fuck apple.

(In reply to comment #4)
> These are actually linker options: I suspect the osx engineers are too lazy to
> use -Wl :/
> 
>      -compatibility_version number
>                  Specifies the compatibility version number of the library. 
> When a library is loaded by dyld, the compati-
>                  bility version is checked and if the program's version is
> greater that the library's version, it is an
>                  error.  The format of number is X[.Y[.Z]] where X must be a
> positive non-zero number less than or equal to
>                  65535, and .Y and .Z are optional and if present must be
> non-negative numbers less than or equal to 255.
>                  If the compatibility version number is not specified, it has a
> value of 0 and no checking is done when the
>                  library is used.  This option is also called
> -dylib_compatibility_version for compatibility.
> 
>      -current_version number
>                  Specifies the current version number of the library. The
> current version of the library can be obtained
>                  programmatically by the user of the library so it can
> determine exactly which version of the library it is
>                  using.  The format of number is X[.Y[.Z]] where X must be a
> positive non-zero number less than or equal to
>                  65535, and .Y and .Z are optional and if present must be
> non-negative numbers less than or equal to 255.
>                  If the version number is not specified, it has a value of 0. 
> This option is also called -dylib_cur-
>                  rent_version for compatibility.
Comment 6 Mathieu Lacage 2011-08-02 07:32:43 UTC
(In reply to comment #5)
> which means that all that is missing for the command-line to work is a number
> after -current_version: what is going on here is that the -Idebug is swallowed
> by the linker to produce a version number. Why on earth did they not use -Wl 

What is amazing is that the missing version number is actually in shlibs:
d-128-95-215-176:ns-3-dev mathieu$ grep -r current_version *
build/c4che/debug.cache.py:shlib_CCFLAGS = ['-fPIC', '-compatibility_version', '1', '-current_version', '1']
build/c4che/debug.cache.py:shlib_CXXFLAGS = ['-fPIC', '-compatibility_version', '1', '-current_version', '1']
build/c4che/default.cache.py:shlib_CCFLAGS = ['-fPIC', '-compatibility_version', '1', '-current_version', '1']
build/c4che/default.cache.py:shlib_CXXFLAGS = ['-fPIC', '-compatibility_version', '1', '-current_version', '1']


it is getting lost somewhere.
Comment 7 Mathieu Lacage 2011-08-02 08:08:54 UTC
changeset 3350424e0466