norm 1.5.9 build failure

[chenrui333]

👋 trying to build the latest release, but run into some build issue. The error log is as below:

build failure

==> ./waf install
Waf: Entering directory `/private/tmp/norm-20210130-97923-fcxwgj/norm-1.5.9/build'
Traceback (most recent call last):
  File "/private/tmp/norm-20210130-97923-fcxwgj/norm-1.5.9/.waf-2.0.19-1f3c580272b15a03d2566843c5fe872a/waflib/Scripting.py", line 119, in waf_entry_point
    run_commands()
  File "/private/tmp/norm-20210130-97923-fcxwgj/norm-1.5.9/.waf-2.0.19-1f3c580272b15a03d2566843c5fe872a/waflib/Scripting.py", line 182, in run_commands
    ctx=run_command(cmd_name)
  File "/private/tmp/norm-20210130-97923-fcxwgj/norm-1.5.9/.waf-2.0.19-1f3c580272b15a03d2566843c5fe872a/waflib/Scripting.py", line 173, in run_command
    ctx.execute()
  File "/private/tmp/norm-20210130-97923-fcxwgj/norm-1.5.9/.waf-2.0.19-1f3c580272b15a03d2566843c5fe872a/waflib/Scripting.py", line 413, in execute
    return execute_method(self)
  File "/private/tmp/norm-20210130-97923-fcxwgj/norm-1.5.9/.waf-2.0.19-1f3c580272b15a03d2566843c5fe872a/waflib/Build.py", line 93, in execute
    self.execute_build()
  File "/private/tmp/norm-20210130-97923-fcxwgj/norm-1.5.9/.waf-2.0.19-1f3c580272b15a03d2566843c5fe872a/waflib/Build.py", line 96, in execute_build
    self.recurse([self.run_dir])
  File "/private/tmp/norm-20210130-97923-fcxwgj/norm-1.5.9/.waf-2.0.19-1f3c580272b15a03d2566843c5fe872a/waflib/Context.py", line 133, in recurse
    user_function(self)
  File "/private/tmp/norm-20210130-97923-fcxwgj/norm-1.5.9/wscript", line 226, in build
    if ctx.options.enable_static_library:
AttributeError: Values instance has no attribute 'enable_static_library'

Full build log is in here, https://github.com/Homebrew/homebrew-core/runs/1800067295
relates to Homebrew/homebrew-core#70083

[bebopagogo]

I made a simple update to waf script to check that the "ctx.options.enable_static_library" exists before trying to access it. This should address the error shown here. However It does not occur on my MacOS system so I'm not exactly yet sure the issue. It is probably some Python package version mismatch as a guess so there could be more to fix. Note that I will need to publish a new release once this is resolved. Is there some way you can test against the Git master to see if it is resolved?

[chenrui333]

@bebopagogo if you can share the commit, I can patch into the existing PR.

Let me give your commit a try.

[chenrui333]

looks like some new error now.

../protolib/include/protoDispatcher.h:60:2: warning: "Neither USE_SELECT or USE_KQUEUE defined, setting USE_SELECT" [-W#warnings]
#warning "Neither USE_SELECT or USE_KQUEUE defined, setting USE_SELECT"
 ^
../src/common/normSession.cpp:5096:17: error: no matching constructor for initialization of 'ProtoPktETH'
    ProtoPktETH ethPkt(ethBuffer, 8192 - 2);
                ^      ~~~~~~~~~~~~~~~~~~~
../protolib/include/protoPktETH.h:63:9: note: candidate constructor not viable: no known conversion from 'UINT16 *' (aka 'unsigned short *') to 'UINT32 *' (aka 'unsigned int *') for 1st argument
        ProtoPktETH(UINT32*         bufferPtr = NULL, 
        ^
../protolib/include/protoPktETH.h:60:7: note: candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 2 were provided
class ProtoPktETH : public ProtoPkt
      ^
../src/common/normSession.cpp:5103:20: error: use of undeclared identifier 'PROTO_ADDR_BROADCAST'
        etherDst = PROTO_ADDR_BROADCAST;
                   ^
1 warning and 2 errors generated.

[bebopagogo]

This looks like an older revision of protolib is being referenced? The approach we are taking with Protolib at the moment since its version control is not carefully managed (or checked with builds, etc) yet is to reference it as a git submodule from the norm code to make sure the appropriate revision is used. So, protolib headers, libraries should not be installed as an inappropriate version might be installed. Do you think that could be the case on your system?

When you do a "git clone" to pull the NORM code, if you use the "git clone --recursive" option, that will pull in the protolib submodule source code tree at the same time. Otherwise, you can do a "git submodule update --init" to do that as a second step from within the the checked out norm source tree.

[bebopagogo]

Did this help resolve the issue? Should I publish a new release with the updated waf file? Or is it unnecessary now?

[chenrui333]

let me give git checkout a try right now.

[bebopagogo]

Hi @chenrui333 - Can this issue be closed?

[chenrui333]

@bebopagogo I think I still have some issue for the build.