--shared-openssl causes configure/gaf failure on io.js 2.3.0 (and 2.{1,2}.\d)

[Haifen]

Hi-
When configuring io.js 2.3.0 (building using Gentoo, invocation of configure script happens from the src_configure() phase of the ebuild), Gaf spat this out:

creating  icu_config.gypi
{ 'target_defaults': { 'cflags': [],
                       'default_configuration': 'Release',
                       'defines': [],
                       'include_dirs': [['/usr/kerberos/include']],
                       'libraries': [ '-L/usr/lib64',
                                      '-lz',
                                      '-lhttp_parser',
                                      '-luv',
                                      '-lrt',
                                      '-lpthread',
                                      '-lnsl',
                                      '-ldl',
                                      '-lssl',
                                      '-lcrypto']},
  'variables': { 'host_arch': 'x64',
                 'icu_small': 'false',
                 'node_install_npm': 'true',
                 'node_prefix': '/usr',
                 'node_shared_http_parser': 'true',
                 'node_shared_libuv': 'true',
                 'node_shared_openssl': 'true',
                 'node_shared_zlib': 'true',
                 'node_tag': '',
                 'node_use_dtrace': 'false',
                 'node_use_etw': 'false',
                 'node_use_lttng': 'false',
                 'node_use_openssl': 'true',
                 'node_use_perfctr': 'false',
                 'openssl_fips': '',
                 'openssl_no_asm': 0,
                 'python': '/usr/bin/python2.7',
                 'target_arch': 'x64',
                 'uv_parent_path': '/deps/uv/',
                 'uv_use_dtrace': 'false',
                 'v8_enable_gdbjit': 0,
                 'v8_enable_i18n_support': 0,
                 'v8_no_strict_aliasing': 1,
                 'v8_optimized_debug': 0,
                 'v8_random_seed': 0,
                 'v8_use_snapshot': 1,
                 'want_separate_host_toolset': 0}}
creating  config.gypi
creating  config.mk
Traceback (most recent call last):
  File "tools/gyp_node.py", line 57, in <module>
    run_gyp(gyp_args)
  File "tools/gyp_node.py", line 18, in run_gyp
    rc = gyp.main(args)
  File "./tools/gyp/pylib/gyp/__init__.py", line 526, in main
    return gyp_main(args)
  File "./tools/gyp/pylib/gyp/__init__.py", line 511, in gyp_main
    generator.GenerateOutput(flat_list, targets, data, params)
  File "./tools/gyp/pylib/gyp/generator/make.py", line 2162, in GenerateOutput
    part_of_all=qualified_target in needed_targets)
  File "./tools/gyp/pylib/gyp/generator/make.py", line 795, in Write
    self.Pchify))
  File "./tools/gyp/pylib/gyp/generator/make.py", line 1212, in WriteSources
    includes = map(Sourceify, map(self.Absolutify, includes))
  File "./tools/gyp/pylib/gyp/generator/make.py", line 1906, in Absolutify
    return os.path.normpath(os.path.join(self.path, path))
  File "/usr/lib64/python2.7/posixpath.py", line 68, in join
    if b.startswith('/'):
AttributeError: 'list' object has no attribute 'startswith'

The configure script invocation that caused the error was:

/usr/bin/python2.7 configure --prefix=/usr --dest-cpu=x64 --without-dtrace --shared-openssl --shared-libuv --shared-http-parser --shared-zlib

After farting around a bit on the commandline, I realized that the --shared-openssl configure option caused the issue.

There is a chance that there is something weird enough about my openssl install that it causes a type error in Python's posixpath.py, but I'm assuming something else may be going on. Ideas?

[bnoordhuis]

@Haifen can you post the output of for FLAG in cflags-only-I libs-only-L libs-only-l; do pkg-config --$FLAG openssl; done?

/cc @jbergstroem

[Haifen]

@bnoordhuis Result is:
-I/usr/kerberos/include

-lssl -lcrypto

I assume -L is omitted because the libraries live in /usr/lib64.
That said, looking at openssl.pc, it defines libdir=${exec_prefix}/lib64, where exec_prefix is /usr.

I assume pkg-config is omitting the library search flag because it's part of the standard search path? Is this normal behavior? Does Gyp expect a -L flag regardless of whether or not specifying one is necessary for compilation?

[jbergstroem]

@Haifen thanks for posting this. If this is from the ebuild you should file a bug at the gentoo bugzilla: http://bugs.gentoo.org. This is probably a whitespace issue parsing pkg-config output.

[bnoordhuis]

@Haifen can you test #1986?

[Haifen]

@jbergstroem It sounds like an issue w/ pkg-config, since the build options above are verbatim from the ebuild and are likely to be what I would use when compiling by hand. That said, I will open a bug and attach bnoordhuis' patch.
@bnoordhuis Yep, it works. Will attach to the Gentoo bug.

[Haifen]

Gentoo bug is at Gentoo's bugtracker (Bug 552232)

[jbergstroem]

@Haifen its most likely not a bug with pkg-config. Parsing its output is just full of compromises. FYI, I'm the maintainer for the gentoo ebuilds (node, iojs) so I'll make sure we get a fix as soon as possible - but since you saw the error from emerge it's better to start in that bug tracker since it might be because of your local configuration.

[bnoordhuis]

Fixed by c207e8d.

[msva]

@jbergstroem I can confirm the bug on all my machines, so it is definitely not because of @Haifen 's local config ;)

[jbergstroem]

@msva didn't say it was because of his config, but it's definitely different depending on what the .pc-files provides.