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

CMake regression: unrecognized command line option stdlib on (some) Linux #49

Closed
utensil opened this issue Apr 3, 2014 · 12 comments
Closed
Assignees
Milestone

Comments

@utensil
Copy link
Member

utensil commented Apr 3, 2014

It seems to be a regression of numenta/nupic-legacy#669 , reappeared at numenta/nupic.core@HEAD after merging #47, or before it, I don't know.

See also http://stackoverflow.com/a/19774902/200764

Details:

Linking CXX executable /home/utensilsong/projects/nupic.core/build/release/bin/testeverything
c++: error: unrecognized command line option ‘-stdlib=libstdc++’
make[2]: *** [/home/utensilsong/projects/nupic.core/build/release/bin/testeverything] Error 1
make[1]: *** [CMakeFiles/testeverything.dir/all] Error 2
make: *** [all] Error 2

Env:

~/projects/nupic.core/build/scripts$ c++ -v                                                                             
Using built-in specs.
COLLECT_GCC=c++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.7.3-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.
Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --libe
xecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-
nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin
 --with-system-zlib --enable-objc-gc --with-cloog --enable-cloog-backend=ppl --disable-cloog-version-check --disable-ppl-version-check --
enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-check
ing=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.7.3 (Ubuntu/Linaro 4.7.3-1ubuntu1)

Seems this needs to be fixed before merging numenta/nupic-legacy#751 , cc @david-ragazzi @rhyolight

@rhyolight rhyolight added this to the Sprint 19 milestone Apr 3, 2014
@rhyolight
Copy link
Member

@utensil Do you know what to do to fix this?

@utensil
Copy link
Member Author

utensil commented Apr 3, 2014

@rhyolight My initial guess is similar to what @david-ragazzi has done in david-ragazzi/nupic.core@425b1f8 and david-ragazzi/nupic.core@33df5c1 , to add this flag only under OSX .

But I need to take a look into numenta/nupic-legacy#669 to see if there's more. Plus according to http://stackoverflow.com/a/19774902/200764 , OS X since Mavericks no longer needs this flag, but I don't know if it still recognizes it, because I don't have a Mac :(

@rhyolight
Copy link
Member

Ok, if you create a PR, I will test on a mac. I'll assign to you. Let me know if you don't have time to work on it. Thank you!

@breznak
Copy link
Member

breznak commented Apr 3, 2014

We've already seen this. (so fix might be found in git log somewhere)
Yes, fix was either removing the -stdlib reference, or calling it different
under linux platform: -str=libstdc++ maybe?
I could check this.

@utensil
Copy link
Member Author

utensil commented Apr 3, 2014

@rhyolight I can create a PR soon.

@david-ragazzi
Copy link
Contributor

@rhyolight My initial guess is similar to what @david-ragazzi has done in david-ragazzi/nupic.core@425b1f8 and david-ragazzi/nupic.core@33df5c1 , to add this flag only under OSX .

@subutai commented about conflicts presented by XCode on Mac and one found solution was add "-stdlib=libstdc++" under OSX build.

Anyway, I shouldn't have add back this flag to Linux build, the question is that I wasn't aware of numenta/nupic-legacy#669 .

@rhyolight @utensil Let me I create the PR to fix this... :-(

@utensil
Copy link
Member Author

utensil commented Apr 3, 2014

Let me I create the PR to fix this... :-(

@david-ragazzi ok

I've looked into numenta/nupic-legacy#669 , its PR is the same as my initial guess.

The only difference I've noticed is that when back in numenta/nupic-legacy#669 , it was using -std=c++11 instead of -std=c++98. I do remember seeing a commit of @rhyolight changing C++ standard back to 98, but I don't remember why and couldn't find an issue about it...

@david-ragazzi
Copy link
Contributor

The only difference I've noticed is that when back in numenta/nupic-legacy#669 , it was using -std=c++11 instead of -std=c++98. I do remember seeing a commit of @rhyolight changing C++ standard back to 98, but I don't remember why and couldn't search a issue about it...

The problem is that Grook machines at Numenta use versions of compilers which still don't use c++11 standard.. I would love this issue was solved in order to we migrate to c++11 ASAP.

@david-ragazzi
Copy link
Contributor

Let me I create the PR to fix this... :-(

Fixed "-stdlib=libstdc++" issue at nupic and nupic.core with my last commits..

@rhyolight
Copy link
Member

@david-ragazzi Which PR?

@utensil
Copy link
Member Author

utensil commented Apr 3, 2014

#50 fixes this. Closing it.

@utensil utensil closed this as completed Apr 3, 2014
@rhyolight
Copy link
Member

🤘

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants