Build failures on OS X

Hello, I'm trying to compile the example but it is failing. I decided to build the library itself to see what's happening there, and that passed except make install (which is optional) fails.

My toolchain:

CMake version 3.9.4
OS X 10.9.5
clang / Apple LLVM version 6.0 (clang-600.0.57)

Here is what actually happens during the builds:

$ pwd
(...)/stepcode
$ mkdir build; cd build
$ cmake .. -DSC_BUILD_SCHEMAS=ALL
(... successful-looking messages except for some warnings:)
CMake Deprecation Warning at CMakeLists.txt:58 (CMAKE_POLICY):
  The OLD behavior for policy CMP0026 will be removed from a future version
  of CMake.
  
  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.
(...)
-- Configuring done
CMake Warning (dev):
  Policy CMP0042 is not set: MACOSX_RPATH is enabled by default.  Run "cmake
  --help-policy CMP0042" for policy details.  Use the cmake_policy command to
  set the policy and suppress this warning.

  MACOSX_RPATH is not specified for the following targets:

   base
   express
   libexppp
   sdai_IFC4
   sdai_ISO15926
   sdai_ap203
   sdai_ap203e2
   sdai_ap209
   sdai_ap210e2
   sdai_ap210e3
   sdai_ap214e3
   sdai_ap219
   sdai_ap227
   sdai_ap235
   sdai_ap238
   sdai_ap239
   sdai_ap240
   sdai_ap242
   sdai_ifc2x3
   sdai_pdm
   stepcore
   stepdai
   stepeditor
   steplazyfile
   steputils

This warning is for project developers.  Use -Wno-dev to suppress it.

-- Generating done
-- Build files have been written to: (...)/stepcode/build
$ make
(... just some benign warnings about style)
$ make install
(... "up-to-date" or "installing")
-- Installing: (...)/stepcode/../sc-install/bin/schema_scanner
CMake Error at schemas/sdai_ISO15926/cmake_install.cmake:31 (file):
  file INSTALL cannot find
  "(...)/stepcode/build/schemas/sdai_ISO15926/entity/SdaiComposition_of_individual.h".
Call Stack (most recent call first):
  data/cmake_install.cmake:36 (include)
  cmake_install.cmake:43 (include)


make: *** [install] Error 1

And when trying to build the example:

$ pwd
(...)/stepcode/example/ap203min
$ mkdir build; cd build
$ cmake .. -DSTEPCODE_ROOT_DIR=../../..
(... successful except for the same two CMake warnings)
-- Generating done
-- Build files have been written to: (...)/stepcode/example/ap203min/build
$ make
(... more style warnings but successful-looking compilation until:)
Scanning dependencies of target express
[  5%] Building C object sc/src/express/CMakeFiles/express.dir/symbol.c.o
[  6%] Building C object sc/src/express/CMakeFiles/express.dir/type.c.o
[  6%] Building C object sc/src/express/CMakeFiles/express.dir/variable.c.o
[  7%] Building C object sc/src/express/CMakeFiles/express.dir/expr.c.o
[  7%] Building C object sc/src/express/CMakeFiles/express.dir/entity.c.o
[  7%] Building C object sc/src/express/CMakeFiles/express.dir/caseitem.c.o
[  8%] Building C object sc/src/express/CMakeFiles/express.dir/stmt.c.o
[  8%] Building C object sc/src/express/CMakeFiles/express.dir/alg.c.o
[ 10%] Building C object sc/src/express/CMakeFiles/express.dir/scope.c.o
[ 10%] Building C object sc/src/express/CMakeFiles/express.dir/schema.c.o
[ 11%] Building C object sc/src/express/CMakeFiles/express.dir/resolve.c.o
[ 11%] Building C object sc/src/express/CMakeFiles/express.dir/lexact.c.o
[ 12%] Building C object sc/src/express/CMakeFiles/express.dir/linklist.c.o
[ 12%] Building C object sc/src/express/CMakeFiles/express.dir/error.c.o
[ 13%] Building C object sc/src/express/CMakeFiles/express.dir/dict.c.o
[ 13%] Building C object sc/src/express/CMakeFiles/express.dir/hash.c.o
[ 13%] Building C object sc/src/express/CMakeFiles/express.dir/memory.c.o
[ 15%] Building C object sc/src/express/CMakeFiles/express.dir/object.c.o
[ 15%] Building C object sc/src/express/CMakeFiles/express.dir/express.c.o
[ 16%] Building CXX object sc/src/express/CMakeFiles/express.dir/ordered_attrs.cc.o
[ 16%] Building C object sc/src/express/CMakeFiles/express.dir/info.c.o
/Stuff/Schewl/UNI2/UROP/printer-sim/2018-08-30-ir/stepcode/src/express/info.c:8:12: fatal error: 'sc_version_string.h' file not found
#  include "sc_version_string.h"
           ^
1 error generated.
make[2]: *** [sc/src/express/CMakeFiles/express.dir/info.c.o] Error 1
make[1]: *** [sc/src/express/CMakeFiles/express.dir/all] Error 2
make: *** [all] Error 2

Is there a problem with the path? I can see the sc_version_string.h file in the build directory of the library itself. Is the library supposed to be installed fully before the example can build?

Tried building the example on a Linux machine, same problem, same file.

(...)/stepcode/src/express/info.c:8:33: fatal error: sc_version_string.h: No such file or directory

CMake version 3.5.1
Ubuntu 16.04
gcc 5.4.0

Ok, I found out the problem. Building the example makes it build stepcode as well, and this is in the build/sc directory. The build/sc directory does include the sc_version_string.cmake script which is supposed to create sc_version_string.h. Trying to run it directly with cmake -P sc_version_string.cmake fails, however:

$ cmake -P sc_version_string.cmake
CMake Error at sc_version_string.cmake:40 (file):
  file failed to open for reading (No such file or directory):

    /SC_VERSION.txt

And indeed SC_VERSION.txt is only in the root directory of stepcode (and so is the .git directory which it looks for first). Copying the sc_version_string.h file generated by building the library itself into build/sc/include solves the issue and the example builds fine, but this is just a workaround.

So perhaps make sure the version string can be generated properly, and add the example build into Travis-CI? As for the make install failure, I'm not sure what is causing this, but it is also not covered by the CI.

it sounds as if the generate step of the cmake process is not firing correctly. Did you see the schema_scanner being built by a sub-process of cmake?

I usually configure with cmake-gui, I'll try with command line tools on Linux and report back

Yes, schema_scanner did get built, I can see this in the cmake output:

-- Compiling schema scanner...
-- Schema scanner built. Running it...
-- Will generate 602 C++ files for sdai_ap203.

Another somewhat relevant issue – when I set the schema (for the project I am using stepcode for) to ap210e3, the linking step failed. The build/CMakeFiles/project.dir/link.txt was:

/Library/Developer/CommandLineTools/usr/bin/c++   -Wl,-search_paths_first -Wl,-headerpad_max_install_names  CMakeFiles/pocgen.dir/src/main.cpp.o  -o bin/project  sc/src/cleditor/libstepeditor.2.0.0.dylib -lsdai_ap210e3_n8232_mim_lf sc/src/clstepcore/libstepcore.2.0.0.dylib sc/src/cldai/libstepdai.2.0.0.dylib sc/src/clutils/libsteputils.2.0.0.dylib sc/src/base/libbase.2.0.0.dylib

I had to manually change it to:

/Library/Developer/CommandLineTools/usr/bin/c++   -Wl,-search_paths_first -Wl,-headerpad_max_install_names  CMakeFiles/pocgen.dir/src/main.cpp.o  -o bin/project sc/schemas/sdai_ap210e3/libsdai_ap210e3.2.0.0.dylib sc/src/cleditor/libstepeditor.2.0.0.dylib sc/src/clstepcore/libstepcore.2.0.0.dylib sc/src/cldai/libstepdai.2.0.0.dylib sc/src/clutils/libsteputils.2.0.0.dylib sc/src/base/libbase.2.0.0.dylib

I.e. -lsdai_ap210e3_n8232_mim_lf wasn't found, so I replaced it with sc/schemas/sdai_ap210e3/libsdai_ap210e3.2.0.0.dylib. This seems like an OS X issue since it should (I assume) reference the dylib as it does in all the other referenced libraries. But it is weird that this doesn't happen with the ap203 schema.

Best to focus on one thing at a time

The version header should be generated by cmake on Linux - I've just done it (for Git, now checking the last release)

Are you using a release or Git master?

Sure, I could open another issue for the latter problem if you want.

I am using the Git version.

what version of CMake do you have on Linux?

I posted my Linux toolchain above:

CMake version 3.5.1
Ubuntu 16.04
gcc 5.4.0

(OS X is my primary workspace though.)

okay, sorry missed that

My CMake is 3.10.2 - so quite a lot different, perhaps the problem lies there.

Is your Linux a standard distro?

sorry - just saw that too!

Well, it reports as a regular Ubuntu via lsb_release -a, but it is running on university machines, so I cannot easily upgrade the toolchain on it. I am currently upgrading CMake on my OS X (it will be 3.12.1) so I'll let you know if it works with the newer version.

okay - and I'll try to reproduce in a VM with Ubuntu image.

Ok, updated to CMake 3.12.1. The same error still:

[ 16%] Building C object sc/src/express/CMakeFiles/express.dir/info.c.o
(...)/stepcode/src/express/info.c:8:12: fatal error: 'sc_version_string.h' file not found
#  include "sc_version_string.h"

Ubuntu 16 LTS with updates (same CMake version as you). It seems to configure and build - if you look at the attached log, are you doing anything different when you build?

The first thing I'd like to solve why the config header is not generated when you build.

ubuntu16-build.log

can you clear the build directory and start a fresh, if this doesn't solve it run build with VERBOSE=1

Sorry for the late response. On Ubuntu, I completely removed stepcode and did a fresh build, and my output for the same commands is pretty much identical. But it is not building the library that fails, it is building the example project that fails.

okay, understood - I've now reproduced it for the example.

The rule to create the version string is only partially working, hence the missing header.
To workaround
$ make version_string
$ make
Also, the default flags for the compiler miss nullptr build-in type - workaround this by configuring with CXX_FLAGS include -std=c++11 (on Linux) - during the cmake step.

Looks like there's some work to do before the next release on this topic.

Is the initial compile problem (missing config header) also resolved on Mac by this?

Also:
in comment
#379 (comment)

you mention a linker error - that you had to amend the command line to correct. It looks like you've replaced the linker library switch by a file path. What was the original error? I'd guess you're missing a directory search switch (-L?)

in your first post there are a number of RPATH issues - probably something is missing for MacOS that needs to be implemented to fix those.

Ok, with:

$ mkdir build; cd build
$ cmake .. -DSTEPCODE_ROOT_DIR=../../..
$ make version_string
$ make

The example project builds fine.

As for the linker error when using ap210e3, if I do not change link.txt, this is what the result is:

$ cmake .. -DSTEPCODE_ROOT_DIR=../../stepcode
** STEPCODE_ROOT_DIR is a relative path; converted to absolute path: (...)/build/../../stepcode.
CMake Deprecation Warning at (...)/stepcode/CMakeLists.txt:58 (CMAKE_POLICY):
  The OLD behavior for policy CMP0026 will be removed from a future version
  of CMake.

  The cmake-policies(7) manual explains that the OLD behaviors of all
  policies are deprecated and that a policy should be set to OLD only under
  specific short-term circumstances.  Projects should be ported to the NEW
  behavior and not rely on setting a policy to OLD.


-- Could NOT find LEMON (missing: LEMON_EXECUTABLE LEMON_TEMPLATE) 
-- Could NOT find PERPLEX (missing: PERPLEX_EXECUTABLE PERPLEX_TEMPLATE) 
-- Assuming compiler is capable of unity build. (SC_UNITY_BUILD=TRUE)
-- Override by setting SC_UNITY_BUILD; TRUE will result in faster build times but *huge* translation units and higher memory use in compilation.
-- Compiling schema scanner...
-- Schema scanner built. Running it...
-- Will generate 4894 C++ files for sdai_ap210e3.
-- Configuring done
CMake Warning (dev):
  Policy CMP0042 is not set: MACOSX_RPATH is enabled by default.  Run "cmake
  --help-policy CMP0042" for policy details.  Use the cmake_policy command to
  set the policy and suppress this warning.

  MACOSX_RPATH is not specified for the following targets:

   base
   express
   libexppp
   sdai_ap210e3
   stepcore
   stepdai
   stepeditor
   steplazyfile
   steputils

This warning is for project developers.  Use -Wno-dev to suppress it.

-- Generating done
-- Build files have been written to: (...)/build
$ make
[  6%] Built target base
[ 15%] Built target steputils
[ 28%] Built target stepdai
[ 91%] Built target stepcore
[ 97%] Built target stepeditor
[ 97%] Linking CXX executable bin/project
ld: library not found for -lsdai_ap210e3_n8232_mim_lf
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [bin/project] Error 1
make[1]: *** [CMakeFiles/project.dir/all] Error 2
make: *** [all] Error 2

I don't think the RPATH warning is relevant, because even during the example project build (which succeeds and uses ap203), it warns about RPATH when running cmake:

  MACOSX_RPATH is not specified for the following targets:

   base
   express
   libexppp
   sdai_ap203
   stepcore
   stepdai
   stepeditor
   steplazyfile
   steputils

the RPATH warning is not related, but it's also probably not implemented as it should be hence my comment.

For the linker, I'd guess we're missing a -L/path/to/lib switch to the linker. Can you try make VERBOSE=1 and see if it prints the linker command line?

I posted the link command already, since the linker invocation is the same as the contents of the generated link.txt file, but here it is again from make VERBOSE=1:

[ 97%] Linking CXX executable bin/project
/usr/local/Cellar/cmake/3.12.1/bin/cmake -E cmake_link_script CMakeFiles/project.dir/link.txt --verbose=1
/Library/Developer/CommandLineTools/usr/bin/c++   -Wl,-search_paths_first -Wl,-headerpad_max_install_names  CMakeFiles/project.dir/src/duplication.cpp.o CMakeFiles/project.dir/src/main.cpp.o  -o bin/project sc/src/cleditor/libstepeditor.2.0.0.dylib -lsdai_ap210e3_n8232_mim_lf sc/src/clstepcore/libstepcore.2.0.0.dylib sc/src/cldai/libstepdai.2.0.0.dylib sc/src/clutils/libsteputils.2.0.0.dylib sc/src/base/libbase.2.0.0.dylib 
ld: library not found for -lsdai_ap210e3_n8232_mim_lf
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[2]: *** [bin/project] Error 1
make[1]: *** [CMakeFiles/project.dir/all] Error 2
make: *** [all] Error 2

The cmake project file for the example uses a regular expression to build the library name for the link using the express glob match as input. Whilst this works for AP203 (due to the simple file name), the AP210e3 library name does not match the exp file name - therefore it fails.

That's not a bug as it stands - the example as-is works, although I suppose it could be enhanced to always use the correct library name.

Ah yes, I actually had a workaround which consisted of changing the SCHEMA_LINK_NAME variable in the CMake file.

So I suppose this issue is now just the fact that make version_string should either run automatically or should be documented when building a project with STEPcode as a dependency.

there is probably a bug in the CMakeLists / modules when generating the version string - I'll investigate this

For the library link error - I do agree it could be more generic, perhaps there's an easy fix - I'll take a look.

there is probably a bug in the CMakeLists / modules when generating the version string - I'll investigate this

For the library link error - I do agree it could be more generic, perhaps there's an easy fix - I'll take a look.

I ran into this issue as well, it's failing to build I was able to build the package by manually invoking these commands.

	cmake -DSC_BUILD_SCHEMAS=ap242 ../
	make version_string
	make sdai_ap242
	make
	make install

I am using cmake 3.12.1
I did notice that the files in cmake/ folder uses depreciated syntax.

For instance
SC_CXX_schema_macros.cmake

  add_custom_command(OUTPUT ${sourceFiles}
    COMMAND ${CMAKE_COMMAND} -DEXE=\"$<TARGET_FILE:exp2cxx>\"  -DEXP=\"${expFile}\"
    -DONESHOT=\"${SC_GENERATE_CXX_ONESHOT}\" -DSDIR=\"${CMAKE_CURRENT_LIST_DIR}\"
    -P ${SC_CMAKE_DIR}/SC_Run_exp2cxx.cmake
    WORKING_DIRECTORY ${CMAKE_CURRENT_LIST_DIR}
    COMMENT "[exp2cxx] Generating ${${PROJECT_NAME}_file_count} C++ files for ${PROJECT_NAME}."
  )

This will not get executed unless you add a dependency to the exported artifact.

That means that even after I manually run the build steps; the ap242 libs and includes are not properly installed.

I can help debug this to get the build files working as expected.

Agreed, I noticed there is a lot of deprecated content in the cmake files!

If you look in develop branch, you'll see I removed some of the compatibility switches and increased the required cmake version. I also rewrote the extensions for detecting Lemon & RE2C. I think further cmake changes are probably necessary.

Currently I'm studying if it's possible (or worthwhile) to add a developer "check" target to cmake / make for static code analysis - I'm playing with smatch and the results are quite useful to avoid introducing errors when making changes. However, perhaps this is only useful for me as a safety net.

The high level of customisation / wrapping of cmake functions makes me question why we've so much machinery around cmake usage - surely it should be simpler.

Agreed, I noticed there is a lot of deprecated content in the cmake files!

If you look in develop branch, you'll see I removed some of the compatibility switches and increased the required cmake version. I also rewrote the extensions for detecting Lemon & RE2C. I think further cmake changes are probably necessary.

Currently I'm studying if it's possible (or worthwhile) to add a developer "check" target to cmake / make for static code analysis - I'm playing with smatch and the results are quite useful to avoid introducing errors when making changes. However, perhaps this is only useful for me as a safety net.

The high level of customisation / wrapping of cmake functions makes me question why we've so much machinery around cmake usage - surely it should be simpler.

Older versions of CMAKE did require this much machinery to generate projects but the newer versions have improved things a lot.

Like you, trying to understand the entire project will take some time and doing a major code refactoring will require fully understanding what the essential data transformations.

a little rant;
Looking at stepfile format and iges before it; I can see why manufacturing is such a mess, with overly expensive machines that needs experts to program their interfaces.

There's an inherent disconnect between the model formats that's being exchanged and the machines that's suppose to turn those into finished pieces.

This is a much bigger problem than I initially anticipated.

Navigation Menu

Repository navigation

Build failures on OS X #379

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Build failures on OS X #379

Description

Activity

AureaNoire commented on Sep 6, 2018

AureaNoire commented on Sep 6, 2018

cshorler commented on Sep 7, 2018

AureaNoire commented on Sep 7, 2018

cshorler commented on Sep 7, 2018

AureaNoire commented on Sep 7, 2018

cshorler commented on Sep 7, 2018

AureaNoire commented on Sep 7, 2018

cshorler commented on Sep 7, 2018

cshorler commented on Sep 7, 2018

AureaNoire commented on Sep 7, 2018

cshorler commented on Sep 7, 2018

AureaNoire commented on Sep 7, 2018

cshorler commented on Sep 7, 2018

cshorler commented on Sep 7, 2018

AureaNoire commented on Sep 8, 2018

cshorler commented on Sep 8, 2018

cshorler commented on Sep 9, 2018

AureaNoire commented on Sep 10, 2018

cshorler commented on Sep 10, 2018

AureaNoire commented on Sep 11, 2018

cshorler commented on Sep 12, 2018

AureaNoire commented on Sep 13, 2018

cshorler commented on Sep 13, 2018

teamblubee commented on Nov 19, 2018

cshorler commented on Nov 23, 2018

teamblubee commented on Nov 24, 2018

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions