Crossbuilt cmake probably is a linux executable about os HOT 7 CLOSED

Yup. It needs to be if test "x$BUILD_OS" != "xminoca"; then. I'm drafting up a change that fixes a few more of these.

from os.

Thanks for catching this. As we use Windows for our main dev environment, we have some

   if test "x$BUILD_OS" = "xwin32"; then

lines that either prevent cross-compiling or take different actions for cross-compiling. Looks like we missed a few on our effort to support Linux / macOS. ~/third-party/build/cmake-3.5.2/build.sh still has one of incorrect checks and it thought it should build for the native OS - Linux in your case.

from os.

\o/   Thanks!!!   \o/

Is if test "x$BUILD_OS" != "xminoca"; then acceptable there? It looks like it worked:

# cmake 
Usage

  cmake [options] <path-to-source>
  cmake [options] <path-to-existing-build>

Specify a source directory to (re-)generate a build system for it in the
current working directory.  Specify an existing build directory to
re-generate its build system.

Run 'cmake --help' for more information.

# uname -a
Minoca minoca 0.3.0.1935-beta-release yeti-2fa9de8 Nov 05 2016 20:33:31 i686

from os.

Maybe I still got some other linuxish builds in ipks on my image. Maybe even some libs opkg needs. This might influence my opkg issue and maybe this explains my git refusing to use https: (didn't mention that before)...

from os.

You may be right, but it would be a different build issue. As far as checks against $BUILD_OS are concerned, the remaining bugs were in building python, boost, cmake, mysql, pip, and ruby - packages that opkg and git do not depend on.

I've got a repro of your opkg issue. I get nothing when I run opkg list-installed. Working on that now.

from os.

binutils?
I think I had an issue with strip and other stuff...
We'll see...

from os.

cmake fix is now in third-party: 25e04d51.

from os.