-
Notifications
You must be signed in to change notification settings - Fork 30.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
io.js all v2.3.4 - v3.0.0 (1) configures incorrect external-openssl flags, (2) FAILs build, (3) lacks rpath mechanism (&/or docs) #2147
Comments
After the aforementioned initial build FAIL after ./configure,
a workaround patch directly to config.gypi,
does the trick. now,
Of course, this needs to be generalized to the io.js configure script ... |
/cc @nodejs/build @jbergstroem you've been working in this area haven't you? |
Yeah, this is up my alley. I'll have a look. |
no new news -- just fyi, same with v2.4.0 |
I swear I posted a diff here last week. Gah - I'll find it. |
Quick question; @pgnd: do you have pkg-config installed in your system? At the moment iojs prefers that before anything else. |
yes, I do. Note that 'my' ssl is installed in a NON-system location. I.e.,
and these are NOT, and shouldn't be in the system pkg-config path,
rather, in the system path, are the system ssl libs/includes,
which are specifically what I am not linking against, and what these configure-options are supposed enable overriding of pkg-config-derived values. |
Yeah, just wanted to make it clear that you will have to either unset pkg-config from path or similar ($i_know_what_im_doing) if you want to make this work. I'll post you a diff for testing shortly. |
Big 'thumbs up' on NOT trying to to be 'auto-magical' about it; you'll never cover all the possible cases. In effect a simple SSL_LIBS & SSL_INCLUDES 'manual override', ensuring the option to add the rpath cruft -- and then making sure that that's what configure actually picks up and inserts into the makefiles is all that's really needed. |
@pgnd we already allow override with flags (so, not 100% autoconf) so that'd be good enough. The behaviour for overridden flags has just changed recently which needs to be adjusted. Finally, I don't think we'll override |
heh, "elaborate". shutting up now. will test / report when you post. thx. |
What's changed in the existing 2.4.0 brach? Now
with no reference at all to my spec'd ssl libs/includes, and a build with this config now appears to build using the bundled source's openssl in ./deps/openssl/openssl , not my specified libs/includes. E.g.
|
Looking at commit history I don't see anything related to above, but the problem you're experiencing is based on this commit since we no longer pick up the defaults, even if passed. |
The commit removes the defaults handling, but iiuc should not interfere with passing the flags on the configure line, right? I'm not clear if a solution has been posted to my OP, or if we're still pending. If it's supposed to be fixed already, then -- it's not working. If it's pending, then I just need to wait some more. |
@pgnd passing flags through configure line would only override the default (through optparse). We need to reintroduce that logic. I'm starting to feel that the only way to really solve this is either moving closer to how autoconf works (i.e, juggling environment variables, pkg-config, default and override flags) or perhaps exposing further configuration through |
@jbergstroem If it were up to me (it's not), if any move were to be made, I'd not recommend autofoo, but rather cmake. That's not a small change, I understand. If OTOH the "modify config.mk/config.gypi" approach is taken for any necessary options, fine with me TBH. That's allow you to simply rip out the 'find SSL' cruft, and use the bundled openssl. +1 on simpler-is-better. For 'advanced' config, then, 3 things would be needed (1) a clear, editable set of FLAGS exposed in config.{mk,gypi} (pretty close already afaict0 |
release 2.5.0 returns back to the originally reported fail mode,
|
Bringing in @bnoordhuis to this discussion as he may have some interest in helping resolve this. I believe @jbergstroem is a little busy with other things atm. |
Sorry, just travelling at the moment. @pgnd I didn't have any problems editing |
No, no problems editing. Just noting that it changed, again, from 2.4.0 -> 2.5.0 At the very least though, this should be corrected
It's just plain wrong. |
Ok, I'll create a PR. |
fell free to reopen if others' interest continues |
I am encountering the same issue with 4.0.0 and 4.1.1. |
Short version: I'm making node from 5.0.0 source on Ubuntu 14.04.3 LTS (GNU/Linux 3.10.53-1.1.0_ga-wandboard-06034-g13bb184-dirty armv7l). Configure options --shared-openssl-includes, --shared-openssl-libpath and --shared-openssl and the same options for zlib don't work as advertised. This may be due to --start-group and --end-group options used in the command that links node. The same failure occurs when building from 4.2.2 source. The command that links node in 4.2.2 and 5.0.0 source differs from the command that links node in 0.12.x source. Longer version:
which results in:
The "libraries" stanza in above is wrong. It should be:
ldd then shows out/Release/node uses these libraries:
whereas the desired ldd output should show references to locally installed libraries (note I have /usr/local/ssl/lib linked to /usr/local/ssl-1.0.2d/lib):
nm shows the undefined symbol isn't in the system version of libssl.so (which was linked into node) but is in the locally installed version of libssl.so (which wasn't, but should have been, linked into node):
g++ -pthread -rdynamic -Wl,-z,noexecstack -Wl,--whole-archive /home/ubuntu/src/nodejs/node-v5.0.0/out/Release/obj.target/deps/v8/tools/gyp/libv8_base.a -Wl,--no-whole-archive -pthread -o /home/ubuntu/src/nodejs/node-v5.0.0/out/Release/node -Wl,--start-group /home/ubuntu/src/nodejs/node-v5.0.0/out/Release/obj.target/node/src/debug-agent.o ... <LOTS MORE REFERENCES TO .o AND .a FILES> ... /home/ubuntu/src/nodejs/node-v5.0.0/out/Release/obj.target/deps/v8/tools/gyp/libv8_nosnapshot.a -Wl,--end-group -L/usr/local/lib -lz -L/usr/local/ssl-1.0.2d/lib -lssl -lcrypto -ldl -lrt -lm which SEEMS to mean -lcrypto -lssl -lz -ldl -lrt -lm that occur after --end-group will never be searched to resolve undefined references in all the archives listed between --start-group and --end-group. In turn the node executable includes undefined symbols (one of which is SSL_set_cert_cb). Subsequently the runtime linker can't resolve the undefineds cause it hasn't been told to look in /usr/local/ssl/lib/.
g++ -pthread -rdynamic -Wl,-z,noexecstack -Wl,--whole-archive /home/ubuntu/src/nodejs/node-v5.0.0/out/Release/obj.target/deps/v8/tools/gyp/libv8_base.a -Wl,--no-whole-archive -pthread -o /home/ubuntu/src/nodejs/node-v5.0.0/out/Release/node -L/usr/local/lib -L/usr/local/ssl-1.0.2d/lib -Wl,--start-group /home/ubuntu/src/nodejs/node-v5.0.0/out/Release/obj.target/node/src/debug-agent.o ... <LOTS MORE REFERENCES TO .o AND .a FILES> ... /home/ubuntu/src/nodejs/node-v5.0.0/out/Release/obj.target/deps/v8/tools/gyp/libv8_nosnapshot.a -lz -lssl -lcrypto -ldl -lrt -lm -Wl,--end-group
|
Making node from 5.0.0 source using locally installed openssl and zlib works if config.gypi and Makefile are edited. For example, configure node with: ./configure --prefix=/usr/local/node-5.0.0 --shared-openssl-includes=/usr/local/ssl/include --shared-openssl-libpath=/usr/local/ssl/lib --shared-openssl --shared-zlib-includes=/usr/local/include --shared-zlib-libpath=/usr/local/lib --shared-zlib After running above configure command, and with node-v5.0.0 as the current directory, edit: A. config.gypi replace:
with:
Note on this machine I've made /usr/local/ssl/lib a soft link to /usr/local/ssl-1.0.2d/lib. B. out/Makefile replace: cmd_link = with: cmd_link = Subsequently continue to make node from source as usual. |
I'm building io.sj v2.3.4 on linux/64.
I've built & installed a local instance of openssl
in
I want to build io.js against that ^^ instance, ensuring proper RUNTIME-linking against the provided libs, NOT system-defaults in other locations, therefore necessitating rpath.
Currently, for io.js,
Configuring with
returns
which appears to
and
Which, of course, causes a build FAIL
Further, there's no obvious mechanism for adding the necessary rpath'ing flags to ensure the aforementioned linking.
For node.js 0.12.x, a simple src patch does the trick
so that node's built & properly runtime-linked,
Looking through io.js' ./configure, it's clearly a departure from node.js', and it's not at all clear, atm, how/where to make a similar patch.
The text was updated successfully, but these errors were encountered: