Lua build fails on OS X / make

[kazimuth]

On OS X, trying to build with lua support and the makefile generator fails with something along the lines of:

clang: error: invalid arch name '-arch -fPIC'

This is because CMakeLists.txt has multiple lines with:

set_target_properties(${NAME} PROPERTIES
    OSX_ARCHITECTURES "$(ARCHS_STANDARD_32_64_BIT)"
)

rather than

set_target_properties(${NAME} PROPERTIES
    OSX_ARCHITECTURES "${ARCHS_STANDARD_32_64_BIT}"
)

Also, ARCHS_STANDARD_32_64_BIT doesn't seem to be defined.

[dwimsey]

What version of Xcode are you using?

Sent from my iPhone

On Nov 19, 2014, at 8:20 PM, James Gilles notifications@github.com wrote:

On OS X, trying to build with lua support and the makefile generator fails with something along the lines of:

clang: error: invalid arch name '-arch -fPIC'
This is because CMakeLists.txt has multiple lines with:

set_target_properties(${NAME} PROPERTIES
OSX_ARCHITECTURES "$(ARCHS_STANDARD_32_64_BIT)"
)
rather than

set_target_properties(${NAME} PROPERTIES
OSX_ARCHITECTURES "${ARCHS_STANDARD_32_64_BIT}"
)
Also, ARCHS_STANDARD_32_64_BIT doesn't seem to be defined.

—
Reply to this email directly or view it on GitHub.

[kazimuth]

6.1, but I'm not actually using it to run the build, I'm only using make and clang.
...and ARCHS_STANDARD_etc are XCode variables, not cmake ones, okay.

Is not using XCode explicitly not supported on OS X?

[dwimsey]

The only testing/builds supported directly are based on Xcode being the environment used.

The supported configurations are with Xcode installed using the Xcode project file generator, though I do generally keep CMake Makefile generator version working. So in theory, I don’t think you should have a problem, BUT it is possible that its a Makefile issue since that is tested only manually when I happen to think off it. Build automation on my end uses xcodebuild for everything.

However, I’ve not upgraded to Xcode 6.1 yet, nor has the build automation environment been updated. Without doing more research (I’m out of town on vacation atm) I can’t say if the problem is related to 6.1 or the Makefile generator.

I suspect that in 6.1 they removed 32 bit support and that variable may have went with it, which means we’ll have to come up with a hack in the CMake file to detect and deal with that. Haven’t looked, so thats just a theory that someone else may be able to confirm sooner than I.

Can you show me your cmake command line and I can run it on my local environment and see if it breaks here?

For reference the $(ARCHS_STANDARD_32_64_BIT) with () instead of {} is used because the value is supposed to be passed as is. Its not a CMake variable like ${NAME} is, its a project/build environment variable that CMake knows nothing about. You might try defining it as an environment variable before starting your build to see if you can eek by in the mean time. Judging by the command line error, it should probably be defined as something like x86_64 or i386, but you won’t get a universal binary out it then, only the target platform you define. Likewise, the appropriate ARM arch if you’re targeting iOS rather than OS X (The OSX_ARCH var is reused in both cases)

On Nov 20, 2014, at 1:34 PM, James Gilles notifications@github.com wrote:

6.1, but I'm not actually using it to run the build, I'm only using make and clang.
...and ARCHS_STANDARD_etc are XCode variables, not cmake ones, okay.

Is not using XCode explicitly not supported on OS X?

—
Reply to this email directly or view it on GitHub #229 (comment).

[dwimsey]

I hate to self reply … but …

I just noticed I had updated my local build environment to 6.1 as well, and I’m seeing the same problem you are, but it doesn’t happen during the core part of the libRocket build, thats very odd.

I see if I can get some more time to look into it this evening.

It does not occur with the Xcode generator using xcodebuild in my instance, if that helps get you a working library for now.

On Nov 20, 2014, at 2:06 PM, David Wimsey david@wimsey.us wrote:

The only testing/builds supported directly are based on Xcode being the environment used.

The supported configurations are with Xcode installed using the Xcode project file generator, though I do generally keep CMake Makefile generator version working. So in theory, I don’t think you should have a problem, BUT it is possible that its a Makefile issue since that is tested only manually when I happen to think off it. Build automation on my end uses xcodebuild for everything.

However, I’ve not upgraded to Xcode 6.1 yet, nor has the build automation environment been updated. Without doing more research (I’m out of town on vacation atm) I can’t say if the problem is related to 6.1 or the Makefile generator.

I suspect that in 6.1 they removed 32 bit support and that variable may have went with it, which means we’ll have to come up with a hack in the CMake file to detect and deal with that. Haven’t looked, so thats just a theory that someone else may be able to confirm sooner than I.

Can you show me your cmake command line and I can run it on my local environment and see if it breaks here?

For reference the $(ARCHS_STANDARD_32_64_BIT) with () instead of {} is used because the value is supposed to be passed as is. Its not a CMake variable like ${NAME} is, its a project/build environment variable that CMake knows nothing about. You might try defining it as an environment variable before starting your build to see if you can eek by in the mean time. Judging by the command line error, it should probably be defined as something like x86_64 or i386, but you won’t get a universal binary out it then, only the target platform you define. Likewise, the appropriate ARM arch if you’re targeting iOS rather than OS X (The OSX_ARCH var is reused in both cases)

On Nov 20, 2014, at 1:34 PM, James Gilles <notifications@github.com mailto:notifications@github.com> wrote:

6.1, but I'm not actually using it to run the build, I'm only using make and clang.
...and ARCHS_STANDARD_etc are XCode variables, not cmake ones, okay.

Is not using XCode explicitly not supported on OS X?

—
Reply to this email directly or view it on GitHub #229 (comment).

[kazimuth]

I was just about to write that, yeah :)
I know that 32-bit builds still work, though, since (I'm slightly ashamed to say) I went through Build/CMakeLists.txt by hand yesterday and replaced all of the "$(ARCHS_STANDARD_32_64_BIT)" with "i386;" and it built fine (with make). (I need to use 32-bit builds because the project I'm integrating with has to be 32-bit, for a variety of reasons.)
It might be possible to just rely on the CMAKE_OSX_ARCHITECTURES variable instead of the XCode ones, although I'm not sure how that will interact with iOS builds.
Thank you so much for your fast reply, by the way.

[kazimuth]

Also, running with

ARCHS_STANDARD_32_64_BIT='i386' ARCHS_STANDARD_32_BIT='i386' make -j 6 VERBOSE=true RocketCoreLua

successfully builds the individual lua objects, but then fails on Linking CXX shared library libRocketCoreLua.dylib:

/usr/bin/clang++  -O3 -DNDEBUG -arch $(ARCHS_STANDARD_32_64_BIT)  ... -o libRocketCoreLua.1.3.0.0.dylib .....
clang: error: invalid arch name '-arch $(ARCHS_STANDARD_32_64_BIT)'

which suggests something is passing through extra-quoted somehow.

[kazimuth]

...on a fresh clone, by the way.

[zykis]

have a same issue
Library successfully builded for x86_64 with the next changes:
adding next definition in the start of CMakeLists.txt:
set(ARCHS_STANDARD_32_64_BIT "x86_64")
and changing all
set(CMAKE_OSX_ARCHITECTURES "$(ARCHS_STANDARD_32_64_BIT)")
to
set(CMAKE_OSX_ARCHITECTURES ${ARCHS_STANDARD_32_64_BIT})

[dwimsey]

The branch feature/xcode6-fixes addresses these issues and will be merged when testing can be completed.