norm 1.5.9 build failure about norm HOT 8 OPEN

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?

from norm.

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

Let me give your commit a try.

from norm.

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.

from norm.

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.

from norm.

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

from norm.

let me give git checkout a try right now.

from norm.

Hi @chenrui333 - Can this issue be closed?

from norm.

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

from norm.