Skip to content
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

FreeBSD with small-icu fails: g++ not found #6152

Closed
srl295 opened this issue Apr 11, 2016 · 8 comments · Fixed by #6173
Closed

FreeBSD with small-icu fails: g++ not found #6152

srl295 opened this issue Apr 11, 2016 · 8 comments · Fixed by #6173
Assignees
Labels
freebsd Issues and PRs related to the FreeBSD platform. i18n-api Issues and PRs related to the i18n implementation.

Comments

@srl295
Copy link
Member

srl295 commented Apr 11, 2016

  • Version: master
  • Platform: FreeBSD 10.3 amd64
  • Subsystem: Intl

Split off from #6088 (comment)

When configured with env CXX=c++ CC=cc ./configure --with-intl=small-icu --download=all I get:

# ( lots of stuff compiled with cc and c++ and then… )  
  g++ '-DU_COMMON_IMPLEMENTATION=1' '-DU_I18N_IMPLEMENTATION=1' '-DU_IO_IMPLEMENTATION=1' '-DU_TOOLUTIL_IMPLEMENTATION=1' '-DU_ATTRIBUTE_DEPRECATED=' '-D_CRT_SECURE_NO_DEPRECATE=' '-DU_STATIC_IMPLEMENTATION=1' '-DUCONFIG_NO_TRANSLITERATION=1' '-DUCONFIG_NO_SERVICE=1' '-DUCONFIG_NO_REGULAR_EXPRESSIONS=1' '-DU_ENABLE_DYLOAD=0' '-DU_HAVE_STD_STRING=0' '-DUCONFIG_NO_BREAK_ITERATION=0' '-DUCONFIG_NO_LEGACY_CONVERSION=1' '-DUCONFIG_NO_IDNA=1' -I../deps/icu-small/source/common -I../deps/icu-small/source/i18n -I../deps/icu-small/source/io -I../deps/icu-small/source/tools/toolutil  -pthread -Wall -Wextra -Wno-unused-parameter -m64 -Wno-deprecated-declarations -O3 -fno-omit-frame-pointer -fno-rtti -fno-exceptions -std=gnu++0x -frtti -MMD -MF /usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd102-64/out/Release/.deps//usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd102-64/out/Release/obj.host/icutools/deps/icu-small/source/tools/toolutil/collationinfo.o.d.raw   -c -o /usr/home/iojs/build/workspace/node-test-commit-freebsd/nodes/freebsd102-64/out/Release/obj.host/icutools/deps/icu-small/source/tools/toolutil/collationinfo.o ../deps/icu-small/source/tools/toolutil/collationinfo.cpp
gmake[2]: g++: Command not found

( I'm copying from https://ci.nodejs.org/job/node-test-commit-freebsd/2017/nodes=freebsd102-64/console but I had the same output locally ).

It's not clear where the g++ is coming from here. I think this is using the host toolset instead of target.

@bnoordhuis
Copy link
Member

It's not clear where the g++ is coming from here. I think this is using the host toolset instead of target.

That's right. It's controlled by the CXX.host environment variable. It defaults (for better or worse) to g++.

@srl295
Copy link
Member Author

srl295 commented Apr 11, 2016

@bnoordhuis Aha! so gmake CXX.host=c++ CC.host=cc seems to get a bit further. Thanks.

Perhaps the jenkins system needs to have this also.. @rvagg ?

@mscdex mscdex added freebsd Issues and PRs related to the FreeBSD platform. i18n-api Issues and PRs related to the i18n implementation. labels Apr 11, 2016
@srl295 srl295 self-assigned this Apr 11, 2016
@jbergstroem
Copy link
Member

Looks like this: https://github.com/nodejs/node/blob/be68b68d4863f0d389cc46fdf6f1cbcd1b241d0a/tools/gyp/pylib/gyp/generator/make.py#L2056..L2065

I wouldn't treat this as FreeBSD only; lets either patch it by setting {CXX,CC}_host to CC/CXX in our Makefile (or override through env) or patch gyp. I can whip this up. Thoughts, @bnoordhuis? Also, just noting that I'm not a fan of what gyp does here.

@bnoordhuis
Copy link
Member

Ideally, it gets fixed in gyp.

@srl295
Copy link
Member Author

srl295 commented Apr 12, 2016

Also here (FreeBSD) host === target. So at least in that case, gyp shouldn't pick a different compiler.

@srl295
Copy link
Member Author

srl295 commented Apr 12, 2016

@jbergstroem if you can whip up a patch that would be great. I'd be happy to keep this issue or turn it over, what ever you prefer.

@jbergstroem
Copy link
Member

@srl295 I'm onto it. I've found a few bugs upstream that tangents modifying the environment default behaviour. I just don't see it change -- but I guess we could carry a patch.

@srl295
Copy link
Member Author

srl295 commented Apr 13, 2016

this should be fixed by #6173 - close when confirmed.

jbergstroem added a commit to jbergstroem/node that referenced this issue Apr 24, 2016
Gyp defaults to gcc/g++ if CC.host/CXX.host is unset. This is not
suitable for environments that only uses the clang toolchain.

Since we already assume that the user will provide clang/clang++
through CC/CXX, lean against it (then drop to gcc/g++).

Also apply the same logic for link/ar for consistency although
it doesn't affect us.

PR-URL: nodejs#6173
Fixes: nodejs#6152
Reviewed-By: João Reis <reis@janeasystems.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
joelostrowski pushed a commit to joelostrowski/node that referenced this issue Apr 25, 2016
Gyp defaults to gcc/g++ if CC.host/CXX.host is unset. This is not
suitable for environments that only uses the clang toolchain.

Since we already assume that the user will provide clang/clang++
through CC/CXX, lean against it (then drop to gcc/g++).

Also apply the same logic for link/ar for consistency although
it doesn't affect us.

PR-URL: nodejs#6173
Fixes: nodejs#6152
Reviewed-By: João Reis <reis@janeasystems.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
jasnell pushed a commit that referenced this issue Apr 26, 2016
Gyp defaults to gcc/g++ if CC.host/CXX.host is unset. This is not
suitable for environments that only uses the clang toolchain.

Since we already assume that the user will provide clang/clang++
through CC/CXX, lean against it (then drop to gcc/g++).

Also apply the same logic for link/ar for consistency although
it doesn't affect us.

PR-URL: #6173
Fixes: #6152
Reviewed-By: João Reis <reis@janeasystems.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
bnoordhuis pushed a commit to bnoordhuis/io.js that referenced this issue Oct 8, 2016
Gyp defaults to gcc/g++ if CC.host/CXX.host is unset. This is not
suitable for environments that only uses the clang toolchain.

Since we already assume that the user will provide clang/clang++
through CC/CXX, lean against it (then drop to gcc/g++).

Also apply the same logic for link/ar for consistency although
it doesn't affect us.

PR-URL: nodejs#6173
Fixes: nodejs#6152
Reviewed-By: João Reis <reis@janeasystems.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
refack pushed a commit that referenced this issue Apr 18, 2017
Gyp defaults to gcc/g++ if CC.host/CXX.host is unset. This is not
suitable for environments that only uses the clang toolchain.

Since we already assume that the user will provide clang/clang++
through CC/CXX, lean against it (then drop to gcc/g++).

Also apply the same logic for link/ar for consistency although
it doesn't affect us.

PR-URL: #6173
Fixes: #6152
Reviewed-By: João Reis <reis@janeasystems.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
evanlucas pushed a commit that referenced this issue Apr 25, 2017
Gyp defaults to gcc/g++ if CC.host/CXX.host is unset. This is not
suitable for environments that only uses the clang toolchain.

Since we already assume that the user will provide clang/clang++
through CC/CXX, lean against it (then drop to gcc/g++).

Also apply the same logic for link/ar for consistency although
it doesn't affect us.

PR-URL: #6173
Fixes: #6152
Reviewed-By: João Reis <reis@janeasystems.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
evanlucas pushed a commit that referenced this issue May 1, 2017
Gyp defaults to gcc/g++ if CC.host/CXX.host is unset. This is not
suitable for environments that only uses the clang toolchain.

Since we already assume that the user will provide clang/clang++
through CC/CXX, lean against it (then drop to gcc/g++).

Also apply the same logic for link/ar for consistency although
it doesn't affect us.

PR-URL: #6173
Fixes: #6152
Reviewed-By: João Reis <reis@janeasystems.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
evanlucas pushed a commit that referenced this issue May 2, 2017
Gyp defaults to gcc/g++ if CC.host/CXX.host is unset. This is not
suitable for environments that only uses the clang toolchain.

Since we already assume that the user will provide clang/clang++
through CC/CXX, lean against it (then drop to gcc/g++).

Also apply the same logic for link/ar for consistency although
it doesn't affect us.

PR-URL: #6173
Fixes: #6152
Reviewed-By: João Reis <reis@janeasystems.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
refack pushed a commit to refack/node that referenced this issue Jul 18, 2017
Gyp defaults to gcc/g++ if CC.host/CXX.host is unset. This is not
suitable for environments that only uses the clang toolchain.

Since we already assume that the user will provide clang/clang++
through CC/CXX, lean against it (then drop to gcc/g++).

Also apply the same logic for link/ar for consistency although
it doesn't affect us.

PR-URL: nodejs#6173
Fixes: nodejs#6152
Reviewed-By: João Reis <reis@janeasystems.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
refack pushed a commit to refack/node that referenced this issue Aug 23, 2017
Gyp defaults to gcc/g++ if CC.host/CXX.host is unset. This is not
suitable for environments that only uses the clang toolchain.

Since we already assume that the user will provide clang/clang++
through CC/CXX, lean against it (then drop to gcc/g++).

Also apply the same logic for link/ar for consistency although
it doesn't affect us.

PR-URL: nodejs#6173
Fixes: nodejs#6152
Reviewed-By: João Reis <reis@janeasystems.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
addaleax pushed a commit to addaleax/ayo that referenced this issue Aug 25, 2017
Gyp defaults to gcc/g++ if CC.host/CXX.host is unset. This is not
suitable for environments that only uses the clang toolchain.

Since we already assume that the user will provide clang/clang++
through CC/CXX, lean against it (then drop to gcc/g++).

Also apply the same logic for link/ar for consistency although
it doesn't affect us.

PR-URL: nodejs/node#6173
Fixes: nodejs/node#6152
Reviewed-By: João Reis <reis@janeasystems.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
addaleax pushed a commit to ayojs/ayo that referenced this issue Aug 28, 2017
Gyp defaults to gcc/g++ if CC.host/CXX.host is unset. This is not
suitable for environments that only uses the clang toolchain.

Since we already assume that the user will provide clang/clang++
through CC/CXX, lean against it (then drop to gcc/g++).

Also apply the same logic for link/ar for consistency although
it doesn't affect us.

PR-URL: nodejs/node#6173
Fixes: nodejs/node#6152
Reviewed-By: João Reis <reis@janeasystems.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
MylesBorins pushed a commit that referenced this issue Sep 10, 2017
Gyp defaults to gcc/g++ if CC.host/CXX.host is unset. This is not
suitable for environments that only uses the clang toolchain.

Since we already assume that the user will provide clang/clang++
through CC/CXX, lean against it (then drop to gcc/g++).

Also apply the same logic for link/ar for consistency although
it doesn't affect us.

PR-URL: #6173
Fixes: #6152
Reviewed-By: João Reis <reis@janeasystems.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
MylesBorins pushed a commit that referenced this issue Sep 12, 2017
Gyp defaults to gcc/g++ if CC.host/CXX.host is unset. This is not
suitable for environments that only uses the clang toolchain.

Since we already assume that the user will provide clang/clang++
through CC/CXX, lean against it (then drop to gcc/g++).

Also apply the same logic for link/ar for consistency although
it doesn't affect us.

PR-URL: #6173
Fixes: #6152
Reviewed-By: João Reis <reis@janeasystems.com>
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
freebsd Issues and PRs related to the FreeBSD platform. i18n-api Issues and PRs related to the i18n implementation.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants