Hey, I just Downloaded openvrml from macports
(port install openvrml)
Now I have a Sample program (pretty_print.cpp from openvrml at sourceforge) that begins like this:
# ifdef HAVE_CONFIG_H
# include <config.h>
# endif
# include <openvrml/vrml97_grammar.h>
# include <openvrml/browser.h>
# include <fstream>
...
then in Xcode, I added the following path and check "recursive" for the Header search path and Lib Search Path:
/opt/local/var/macports/software
And all '***.h file not found' errors disappeared, but now I have the following two:
complex.h 943 '__pow_helper' is not a member of std
c++locale.h 71 'vsnprintf' is not a member of std
/Developer/SDKs/MacOSX10.6.sdk/usr/include/c++/4.2.1/complex: In function 'std::complex<_Tp> std::pow(const std::complex<_Tp>&, int)':
/Developer/SDKs/MacOSX10.6.sdk/usr/include/c++/4.2.1/complex:943: error: '__pow_helper' is not a member of 'std'
both errors come from system files.
I wonder what is causing this errors...
Can anyone advice me on how to use openvrml samples on Macs?
thanks in advance.
I've had a similar problem. I defined "recursive" flag for an '/opt/local/include' path. This pulled in some strange c++ headers from boost compatiblity includes.
In general, you do not want "recursive" flag on your include paths.
Try unchecking "recursive" from your paths.
if you put recursive on a path containing boost headers you'll use some random boost headers, which are likely designed to be used in different environment and/or different compiler, instead of standard C++ headers, meaning, for example, you'll include TR1 header instead of standard header. This is likely to be the cause of your problem (it happened to me too).
Just locate the directory which contains the headers you need and put only that in header search path instead of being lazy and using "recursive" flag, since there are a lot of header files which have same name but differ in location only.
Related
I'm looking to compile OCCT 7.5 in Windows 10 (x64 via VS2019) for use with FreeCAD, to enable exporting glTF files, which requires RapidJSON support (in OCCT). I've checked out OCCT 7.5.3 and RapidJSON 1.1.0 from their git repos, then grabbed the FreeCAD libpack 12.5.2 (for OCCT 7.5). I started from FreeCAD's build docs, then attempted to follow OCCT's build docs.
When configuring the OCCT project in CMake-GUI, I've been able to find what I think are correct values for some variables (e.g. those regarding FREETYPE) within the FreeCAD libpack, as well as RapidJSON, but still get some errors in the config, seemingly no matter what values I try:
Could not find headers of used third-party products:
3RDPARTY_TCL_INCLUDE_DIR 3RDPARTY_TK_INCLUDE_DIR
...
Could not find DLLs of used third-party products: 3RDPARTY_TCL_DLL_DIR
3RDPARTY_TK_DLL_DIR
I've tried using *.lib, *.h and *.dll files found within the FreeCAD Libpack (and their corresponding directories) for *_LIBRARY/INCLUDE/DLL variables, but nothing is found. I see
Info: TCL is used by OCCT
Could NOT find Tclsh (missing: TCL_TCLSH)
even though tclsh86t.exe exists in the libpack/bin directory.
What should the 3RDPARTY_TCL_* & 3RDPARTY_TK_* CMake variables be set to, to use the FreeCAD libpack?
The problem was my lack of familiarity with CMake and Cmake-gui: the gui opened a dialog for a FILEPATH when specifying a PATH variable. I naively thought, "I don't know CMake, so I'll trust the gui". Totally wrong.
I manually edited the 3RDPARTY_* variable entries to point to the correct directories (or libs, when needed) in the FreeCAD libpack, using the variable name and description/hint for each to determine what the variable's value should be. Below are my entries, for reference:
I did need to check "Advanced", to edit the FREETYPE_LIBRARY_DEBUG & FREETYPE_LIBRARY_RELEASE variables (CMake set them to separate libs found in a jdk directory, presumably because it was added to the system path at some point).
How to get CMake to link an executable to an external shared library that is not build within the same CMake project?
Just doing target_link_libraries(GLBall ${CMAKE_BINARY_DIR}/res/mylib.so) gives the error
make[2]: *** No rule to make target `res/mylib.so', needed by `GLBall'. Stop.
make[1]: *** [CMakeFiles/GLBall.dir/all] Error 2
make: *** [all] Error 2
(GLBall is the executable)
after I copied the library into the binary dir bin/res.
I tried using find_library(RESULT mylib.so PATHS ${CMAKE_BINARY_DIR}/res)
Which fails with RESULT-NOTFOUND.
arrowdodger's answer is correct and preferred on many occasions. I would simply like to add an alternative to his answer:
You could add an "imported" library target, instead of a link-directory. Something like:
# Your-external "mylib", add GLOBAL if the imported library is located in directories above the current.
add_library( mylib SHARED IMPORTED )
# You can define two import-locations: one for debug and one for release.
set_target_properties( mylib PROPERTIES IMPORTED_LOCATION ${CMAKE_BINARY_DIR}/res/mylib.so )
And then link as if this library was built by your project:
TARGET_LINK_LIBRARIES(GLBall mylib)
Such an approach would give you a little more flexibility: Take a look at the add_library( IMPORTED) command and the many target-properties related to imported libraries.
I do not know if this will solve your problem with "updated versions of libs".
Set libraries search path first:
link_directories(${CMAKE_BINARY_DIR}/res)
And then just do
target_link_libraries(GLBall mylib)
I assume you want to link to a library called foo, its filename is usually something link foo.dll or libfoo.so.
1. Find the library
You have to find the library. This is a good idea, even if you know the path to your library. CMake will error out if the library vanished or got a new name. This helps to spot error early and to make it clear to the user (may yourself) what causes a problem.
To find a library foo and store the path in FOO_LIB use
find_library(FOO_LIB foo)
CMake will figure out itself how the actual file name is. It checks the usual places like /usr/lib, /usr/lib64 and the paths in PATH.
You already know the location of your library. Add it to the CMAKE_PREFIX_PATH when you call CMake, then CMake will look for your library in the passed paths, too.
Sometimes you need to add hints or path suffixes, see the documentation for details:
https://cmake.org/cmake/help/latest/command/find_library.html
2. Link the library
From 1. you have the full library name in FOO_LIB. You use this to link the library to your target GLBall as in
target_link_libraries(GLBall PRIVATE "${FOO_LIB}")
You should add PRIVATE, PUBLIC, or INTERFACE after the target, cf. the documentation:
https://cmake.org/cmake/help/latest/command/target_link_libraries.html
If you don't add one of these visibility specifiers, it will either behave like PRIVATE or PUBLIC, depending on the CMake version and the policies set.
3. Add includes (This step might be not mandatory.)
If you also want to include header files, use find_path similar to find_library and search for a header file. Then add the include directory with target_include_directories similar to target_link_libraries.
Documentation:
https://cmake.org/cmake/help/latest/command/find_path.html
and
https://cmake.org/cmake/help/latest/command/target_include_directories.html
If available for the external software, you can replace find_library and find_path by find_package.
Let's say you have an executable like:
add_executable(GLBall GLBall.cpp)
If the external library has headers, give the path to its include folder:
target_include_directories(GLBall PUBLIC "/path/to/include")
Add the library directory path:
target_link_directories(GLBall PUBLIC "/path/to/lib/directory")
Finally, link the library name
target_link_libraries(GLBall mylib)
Note that the prefix and extension of the library file are removed:
libmylib.a ➜ mylib
mylib.so ➜ mylib
One more alternative, in the case you are working with the Appstore, need "Entitlements" and as such need to link with an Apple-Framework.
For Entitlements to work (e.g. GameCenter) you need to have a "Link Binary with Libraries"-buildstep and then link with "GameKit.framework". CMake "injects" the libraries on a "low level" into the commandline, hence Xcode doesn't really know about it, and as such you will not get GameKit enabled in the Capabilities screen.
One way to use CMake and have a "Link with Binaries"-buildstep is to generate the xcodeproj with CMake, and then use 'sed' to 'search & replace' and add the GameKit in the way XCode likes it...
The script looks like this (for Xcode 6.3.1).
s#\/\* Begin PBXBuildFile section \*\/#\/\* Begin PBXBuildFile section \*\/\
26B12AA11C10544700A9A2BA \/\* GameKit.framework in Frameworks \*\/ = {isa = PBXBuildFile; fileRef = 26B12AA01C10544700A9A2BA \/\* GameKit.framework xxx\*\/; };#g
s#\/\* Begin PBXFileReference section \*\/#\/\* Begin PBXFileReference section \*\/\
26B12AA01C10544700A9A2BA \/\* GameKit.framework xxx\*\/ = {isa = PBXFileReference; lastKnownFileType = wrapper.framework; name = GameKit.framework; path = System\/Library\/Frameworks\/GameKit.framework; sourceTree = SDKROOT; };#g
s#\/\* End PBXFileReference section \*\/#\/\* End PBXFileReference section \*\/\
\
\/\* Begin PBXFrameworksBuildPhase section \*\/\
26B12A9F1C10543B00A9A2BA \/\* Frameworks \*\/ = {\
isa = PBXFrameworksBuildPhase;\
buildActionMask = 2147483647;\
files = (\
26B12AA11C10544700A9A2BA \/\* GameKit.framework in Frameworks xxx\*\/,\
);\
runOnlyForDeploymentPostprocessing = 0;\
};\
\/\* End PBXFrameworksBuildPhase section \*\/\
#g
s#\/\* CMake PostBuild Rules \*\/,#\/\* CMake PostBuild Rules \*\/,\
26B12A9F1C10543B00A9A2BA \/\* Frameworks xxx\*\/,#g
s#\/\* Products \*\/,#\/\* Products \*\/,\
26B12AA01C10544700A9A2BA \/\* GameKit.framework xxx\*\/,#g
save this to "gamecenter.sed" and then "apply" it like this ( it changes your xcodeproj! )
sed -i.pbxprojbak -f gamecenter.sed myproject.xcodeproj/project.pbxproj
You might have to change the script-commands to fit your need.
Warning: it's likely to break with different Xcode-version as the project-format could change, the (hardcoded) unique number might not really by unique - and generally the solutions by other people are better - so unless you need to Support the Appstore + Entitlements (and automated builds), don't do this.
This is a CMake bug, see http://cmake.org/Bug/view.php?id=14185 and http://gitlab.kitware.com/cmake/cmake/issues/14185
It has been a long time since the question was posted but I am leaving this one just for reference.
I have a blog post describing step-by-step almost what you (or anyone else) were trying to do.
Please check here: https://michae9.wordpress.com/2022/09/01/shared-lib-to-be-used-by-client-programs-with-cmake/
I apologize in advance for my lack of experience with m4sh.
I have a configure.ac file containing the following lines:
AC_INIT([libhelloworld], [2.5])
...
AC_OUTPUT([
Makefile
src/helloworld-${PACKAGE_VERSION}.pc
src/Makefile
])
The reason behind the argument of AC_OUTPUT() is that I would like to avoid to copy and paste the new version of my program in multiple places on every update. Therefore I decided to exploit the PACKAGE_VERSION macro, automatically defined when invoking AC_INIT() at the beginning of configure.ac.
The line src/helloworld-${PACKAGE_VERSION}.pc then correctly expands into src/helloworld-2.5.pc and everything seems to be working fine. However I have a couple of questions.
I use ${PACKAGE_VERSION} as a shell variable, but PACKAGE_VERSION itself is a m4 macro. Can I trust that this will always work? Will it always be defined as such when AC_OUTPUT() is invoked?
Are there other ways of obtaining the value of PACKAGE_VERSION within configure.ac? For example, if instead of configure.ac I were inside Makefile.am I would not use the curly brackets, but the command evaluation syntax instead, as in $(PACKAGE_VERSION). What is the proper correct way of doing what I want within configure.ac?
The documentation for AC_INIT states that PACKAGE_VERSION is an "output variable", meaning when you call AC_INIT, something like this gets executed:
AC_SUBST([PACKAGE_VERSION], [2.5])
This allows the configuration of input files such as Makefile.in (generated from Makefile.am) to rely on #PACKAGE_VERSION# inside those files being replaced by 2.5.
There's nothing wrong with your approach if it works, but you might consider using AS_VAR_SET([hello_version], [AC_PACKAGE_VERSION]) to set the hello_version shell variable and src/helloworld-${hello_version}.pc in Autoconf input. This way, even if Autoconf no longer exposes a PACKAGE_VERSION shell variable in some future release, your code won't break because you'll be relying upon your own hello_version variable.
As an aside, it's a bit irregular to use helloworld-2.5.pc when the helloworld version is 1.0 or greater (i.e. the API is stable). It's common to see helloworld.pc, except then there's the problem of what happens when you release 3.0 and replace the installed 2.x version of helloworld.pc with the 3.0 version: assuming you're using semantic versioning, 3.0 is incompatible with 2.x, and any code relying on something like pkg-config --libs helloworld will break.
You might then consider using helloworld-2.pc instead and when you release 3.0, you'd instead have helloworld-3.pc to avoid users of your library linking the incorrect/incompatible library (and also allowing users the option of moving to the new version at their own pace); one can also apply this idea in Automake for a version-specific header directory:
## SOURCE PATH => INSTALL PATH
## include/hello.h => $(includedir)/helloworld-2/hello.h
helloincludedir = #includedir#/helloworld-#hello_major#
helloinclude_HEADERS = include/hello.h
Autoconf also allows you to specify an output file's inputs, so an output file src/helloworld-${hello_major}.pc in the build directory could be generated from src/helloworld.pc.in in the source directory without you needing to update the src/helloworld.pc.in filename when moving from 2.x to 3.0; this could also be used with AC_INIT if you're OK with macros, allowing you to control the version info in one central location:
m4_define([hello_version_major], [2]) dnl
m4_define([hello_version_minor], [5]) dnl
m4_define([hello_version], [hello_version_major[.]hello_version_minor]) dnl
AC_PREREQ([2.69])
AC_INIT([libhelloworld], [hello_version])
AS_VAR_SET([hello_major], [hello_version_major])
AS_VAR_SET([hello_minor], [hello_version_minor])
# For automake and configuration of pkg-config file
AC_SUBST([hello_major])
AC_SUBST([hello_minor])
AC_SUBST([hello_version])
...
AC_CONFIG_FILES([
Makefile
src/Makefile
src/helloworld-]hello_version_major[.pc:src/helloworld.pc.in
])
AC_OUTPUT
I realize it looks surprisingly more complicated than one might expect, but that's Autoconf for you. Note that I had to use some odd quoting in AC_CONFIG_FILES to make use of the macro. Using
src/helloworld-${hello_major}.pc:src/helloworld.pc.in
instead of the macro resulted in a crippled config.status file being generated in Autoconf 2.69 (try config.status with no arguments, then config.status src/helloworld-2.pc to see the issue); I haven't tested any other versions. I've reported the bug, but the macro works until the next release.
I use VS2015+ wxwideget 3.10 to run a very simple example from wxwidget examples
Yesterday this example was able to run properly but today the example starts to display "Error C1189 #error: "wxUSE_ACTIVEX must be defined." when building it. I didn't change the configuration settings so this thing is quite confusing. Where could be the bugs?
the place where error occured(in chkconf.h):
f/* ensure that MSW-specific settings are defined */
#ifndef wxUSE_ACTIVEX
# ifdef wxABORT_ON_CONFIG_ERROR
# error "wxUSE_ACTIVEX must be defined."
# else
# define wxUSE_ACTIVEX 0
# endif
#endif /* !defined(wxUSE_ACTIVEX) */
my property settings:
additional include directories: $(WXWIN)\include; $(WXWIN)\include\msvc;
additional library directories: $(WXWIN)\lib\vc_x64_lib
First of all, it's completely impossible that something that worked yesterday stopped working today without anything else. You did change something and, of course, only you know what it was.
Second, all wxUSE_XXX constants are defined in include/wx/msw/setup.h which is copied to lib/vc_x64_lib/mswu/wx (or another similar directory depending on debug/release, lib/DLL build settings) during the library build and is found there by by include/msvc/wx/setup.h. So if it's not defined, the first thing to do is to check that this file didn't get changed somehow (maybe accidentally, although I have trouble imagining how this could happen).
I am trying to build Veins-LTE 1.3, which includes inet, simulte and veins for LTE-based vehicular networks simulations.
By following the README, I get into the root package and write:
make makefiles //this creates the required Makefile in inet, veins and simulte
make
This last command, however, results into a fatal error in building inet:
In file included from applications/common/ApplicationBase.h:21:10:
fatal error: 'OperationalBase.h': file not found
By opening the file 'inet/src/applications/common/ApplicationBase.h', I immediately realize that the problem lies in the inclusion of the 'OperationalBase.h', which, as a matter of fact, is not present in the same directory. Instead, it can be found in the 'inet/src/base/' directory.
Omnet++ : 5.2.
Veins-LTE: inet 2.3.0, veins 2.1bis, simulte 0.9.1
SUMO: 0.30.0 (if this could be relevant)
Environment: Ubuntu 16.04.1 - amd64
I am perfectly conscious that a similar question already exists here, but it has not received answers nor comments since last August, so..
WHAT I TRIED TO DO:
My first action was simply to change the path in the include statement so that to point to the right folder: #include "../../base/OperationalBase.h"; this actually shifts the problem elsewhere, since all the other source files in the 'inet' framework inside the veins-lte package do not include the full paths of the required header files (i.e., they seem to assume all the .h files are inside the same directory). Moreover, the omnetpp methods are not recognized, since no using namespace omnetpp is present.
I had a look at 'inet/Makefile' file; in particular, after changing to the 'src/' folder, the opp_makemake command comes with the following options:
opp_makemake -f --deep --make-so -o inet -O out -pINET -
Xapplications/voipstream -Xtransport/tcp_lwip -Xtransport/tcp_nsc -
DWITH_TCP_COMMON .... and other stuff sounding like -DWITH_
As per the opp_makemake documentation (opp_makemake), the --deep option should cater for deep includes. Does it mean that the full (or relative to src/) path of the .h file to be included is not required? The only source folders that are excluded seem to be transport/tcp_lwip, applications/voipstream, transport/tcp_nsc.
So, should I modify all source files by writing the full/relative path of the included files?
Is there a better, smarter, more centralized way to achieve this goal, maybe by modifying something in the inet/Makefile file?
Am I missing something very obvious?
Thank You
WHAT I AM ABLE TO DO:
Successfully run the Omnet++ TicToc examples;
Successfully run the veins RSU Example (by using the stand-alone veins
release)
Successfully run basic SUMO examples.