nodejs: Headers from the c-ares port conflict with the bundled c-ares headers

[david.easter@…]

"-I/opt/local/include" precedes "-I../deps/c-ares" in the build command. If the c-ares port is installed but is of a different version than c-ares bundled with nodejs, differences in the header files can cause build errors. A work-around is to upgrade the c-ares port to the latest version.

This is the relevant part of the build command:

/usr/bin/g++-4.0 [...] -I/opt/local/include [...] -Idefault/deps/c-ares -I../deps/c-ares -Idefault/deps/c-ares/darwin-x86 -I../deps/c-ares/darwin-x86

---

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_nodejs/work/node-v0.2.5$ sudo /usr/bin/make all
Waf: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_nodejs/work/node-v0.2.5/build'
DEST_OS: darwin
DEST_CPU: x86
Parallel Jobs: 1
[59/69] cxx: src/node_cares.cc -> build/default/src/node_cares_4.o
/usr/bin/g++-4.0 -O2 -arch i386 -DEV_MULTIPLICITY=0 -pthread -g -O3 -I/opt/local/include -I/opt/local/include -DHAVE_OPENSSL=1 -DX_STACKSIZE=65536 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DHAVE_FDATASYNC=0 -DPLATFORM="darwin" -DNDEBUG -Idefault/src -I../src -Idefault/deps/libeio -I../deps/libeio -Idefault/deps/http_parser -I../deps/http_parser -Idefault/deps/v8/include -I../deps/v8/include -Idefault/deps/libev -I../deps/libev -Idefault/deps/c-ares -I../deps/c-ares -Idefault/deps/c-ares/darwin-x86 -I../deps/c-ares/darwin-x86 -I/opt/local/include -Ideps/v8/include ../src/node_cares.cc -c -o default/src/node_cares_4.o
../src/node_cares.cc: In function ‘void node::ParseAnswerMX(node::QueryArg*, unsigned char*, int)’:
../src/node_cares.cc:347: error: ‘ares_parse_mx_reply’ was not declared in this scope
../src/node_cares.cc:356: error: invalid use of undefined type ‘struct node::ares_mx_reply’
../src/node_cares.cc:345: error: forward declaration of ‘struct node::ares_mx_reply’
../src/node_cares.cc:359: error: invalid use of undefined type ‘struct node::ares_mx_reply’
../src/node_cares.cc:345: error: forward declaration of ‘struct node::ares_mx_reply’
../src/node_cares.cc:360: error: invalid use of undefined type ‘struct node::ares_mx_reply’
../src/node_cares.cc:345: error: forward declaration of ‘struct node::ares_mx_reply’
Waf: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_nodejs/work/node-v0.2.5/build'
Build failed:  -> task failed (err #1): 
	{task: cxx node_cares.cc -> node_cares_4.o}
make: *** [all] Error 1

[david.easter@…]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Is this still an issue with nodejs 0.4.1?

[david.easter@…]

Yes. With c-ares@1.7.0_0 installed:

/usr/bin/g++-4.0 [...] -I/opt/local/include [...] -Idefault/deps/c-ares -I../deps/c-ares -Idefault/deps/c-ares/darwin-ia32 -I../deps/c-ares/darwin-ia32

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_nodejs/work/node-v0.4.2$ sudo /usr/bin/make all
Waf: Entering directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_nodejs/work/node-v0.4.2/build'
DEST_OS: darwin
DEST_CPU: ia32
Parallel Jobs: 1
Product type: program
[61/74] cxx: src/node_cares.cc -> build/default/src/node_cares_4.o
/usr/bin/g++-4.0 -O2 -arch i386 -pthread -arch i386 -m32 -g -O3 -I/opt/local/include -I/opt/local/include -DHAVE_OPENSSL=1 -DEV_FORK_ENABLE=0 -DEV_EMBED_ENABLE=0 -DEV_MULTIPLICITY=0 -DX_STACKSIZE=65536 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DEV_MULTIPLICITY=0 -DHAVE_FDATASYNC=0 -DPLATFORM="darwin" -D__POSIX__=1 -Wno-unused-parameter -D_FORTIFY_SOURCE=2 -DNDEBUG -Idefault/src -I../src -Idefault/deps/libeio -I../deps/libeio -Idefault/deps/http_parser -I../deps/http_parser -Idefault/deps/v8/include -I../deps/v8/include -Idefault/deps/libev -I../deps/libev -Idefault/deps/c-ares -I../deps/c-ares -Idefault/deps/c-ares/darwin-ia32 -I../deps/c-ares/darwin-ia32 -I/opt/local/include -Ideps/v8/include ../src/node_cares.cc -c -o default/src/node_cares_4.o
../src/node_cares.cc: In function ‘void node::ParseAnswerMX(node::QueryArg*, unsigned char*, int)’:
../src/node_cares.cc:367: error: ‘ares_parse_mx_reply’ was not declared in this scope
../src/node_cares.cc:376: error: invalid use of undefined type ‘struct node::ares_mx_reply’
../src/node_cares.cc:365: error: forward declaration of ‘struct node::ares_mx_reply’
../src/node_cares.cc:379: error: invalid use of undefined type ‘struct node::ares_mx_reply’
../src/node_cares.cc:365: error: forward declaration of ‘struct node::ares_mx_reply’
../src/node_cares.cc:380: error: invalid use of undefined type ‘struct node::ares_mx_reply’
../src/node_cares.cc:365: error: forward declaration of ‘struct node::ares_mx_reply’
Waf: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_ports_devel_nodejs/work/node-v0.4.2/build'
Build failed:  -> task failed (err #1): 
	{task: cxx node_cares.cc -> node_cares_4.o}
make: *** [program] Error 1

It works if c-ares@1.7.4_0 is installed, but it's still finding the includes at /opt/local/include (from the c-ares port) instead of the ones bundled with nodejs.

[ryandesign (Ryan Carsten Schmidt)]

Has duplicate #29072.

[ryandesign (Ryan Carsten Schmidt)]

See also #28562, a similar conflict but with the libev port. In r78171 I expanded the error message I added there, to also trigger if c-ares is installed.

[jmroot (Joshua Root)]

Fixed, r87475. Upstream really needs to make sure their internal include paths come first; has this been reported to them?

[ci42]

Replying to jmr@…:

Fixed, r87475. Upstream really needs to make sure their internal include paths come first; has this been reported to them?

+# build system doesn't ensure its internal include paths come first (#28066)
+configure.cppflags      -isystem ${prefix}/include

The change did not fixed the problem. As you can see in the build.arg-append section in the portfile the configure.cppflags are not used. And even if the configure.cppflags were used the macports headers would be found first as the '-isystem' directories are searched after '-I' directories.

Actually this was not a problem before your change because the configure.cppflags were not used. The same applies for #28562 and #29927. However, removing the warning and installation prevention should have been done earlier as well as closing the tickets.