Hello Brad,
Thanks for finding the issue. I had simply replaced the shared library
I was using with the name of the TARGET_OBJECTS generator.
The shared objects are great. It helps me bypass Apple security issues
when a system interpreter loads a shared library, which loads another
shared
On 06/26/2018 01:32 PM, Juan E. Sanchez wrote:
> The likely problem is that the symdiff_objects and the symdiff_tcl are
> in side-by-side directories. They are both added using ADD_SUBDIRECTORY
> one level up. If I put symdiff_python before symdiff_tcl, then that
> target will fail. Please
Hi,
The likely problem is that the symdiff_objects and the symdiff_tcl are
in side-by-side directories. They are both added using ADD_SUBDIRECTORY
one level up. If I put symdiff_python before symdiff_tcl, then that
target will fail. Please fix your Makefile generator.
Regards,
Juan
On
On 06/25/2018 03:09 PM, Juan E. Sanchez wrote:
> ADD_LIBRARY(symdiff_objects OBJECT ${CXX_SRCS} ${MC_SRCS})
> set_property(TARGET symdiff_objects PROPERTY POSITION_INDEPENDENT_CODE ON)
> TARGET_LINK_LIBRARIES (symdiff_tcl $
> ${TCL_ARCHIVE})
>
> How do I tell cmake to wait?
Strange, our test
Hi,
I am getting a race condition when I do a parallel build.
Having an OBJECT library in one directory:
ADD_LIBRARY(symdiff_objects OBJECT ${CXX_SRCS} ${MC_SRCS})
set_property(TARGET symdiff_objects PROPERTY POSITION_INDEPENDENT_CODE ON)
And then having that object library being used in