wxWidgets fails to build due to missing wxxml.lib - visual-c++

Apparently anything GUI-related in terms of components involves XML. I cannot go around actually configuring and building wxWidgets from source because of that. I'm new to wxWidgets.
My current setup is on Win10 with MSVC v141 (Visual Studio 2017) with the latest CMake version (currently 3.21).
Inside the config.cmake of the wxWidgets projects (using latest master branch) I see
wx_get_dependencies(EXTRALIBS_XML xml)
I am also calling CMake with -DwxUSE_XML=ON (among other parameters) but this still leads to:
the XML dependency is nowhere to be found
respectively it's not built
Linking then fails with the following error:
LINK : fatal error LNK1104: cannot open file 'wxxml.lib' [C:\Users\...\CMakeBuilds\ef5b5ada-ee42-7735-988a-ae37c735ccff\build\deps\build\wxwidgets\libs\qa\wxqa.vcxproj]
What library is actually wxWidgets using and how do I trigger it's retrieval and accordingly configuration and building? Since I am adding wxWidgets to my CMake project as an ExternalProject component, I would appreciated something in that line of thought. However any kind of information regarding this issue is more than welcome especially since it will shine light on how to configure other features (if I want them in the future) such as WebView.

The wxxml.lib issue is fixed now. While fixing it I also discovered a bug (of sort) in the build system of wxWidgets.
The reason why it failed to build this library in particular was actually quite simple but due to the lack of knowledge in the dependencies of wxWidgets. I thought that wxWidgets, given it depends on XML so much, has its own XML parser. Well, not really. The wxXML component actually uses and underlying 3rd party dependency called EXPAT, which - as you can see in my question - I have deactivated since it was giving me issues during the build (due to the still present problem of not being able to automatically retrieve dependencies).
What I did was to clone the libexpat repository, add it as an ExternalProject, set the variables for the libraries and include directory and pass them onto my wxWidgets project. But there is a catch...
The expat.cmake file looks as follows:
#############################################################################
# Name: build/cmake/lib/expat.cmake
# Purpose: Use external or internal expat lib
# Author: Tobias Taschner
# Created: 2016-09-21
# Copyright: (c) 2016 wxWidgets development team
# Licence: wxWindows licence
#############################################################################
if(wxUSE_EXPAT STREQUAL "builtin")
# TODO: implement building expat via its CMake file, using
# add_subdirectory or ExternalProject_Add
wx_add_builtin_library(wxexpat
src/expat/expat/lib/xmlparse.c
src/expat/expat/lib/xmlrole.c
src/expat/expat/lib/xmltok.c
)
set(EXPAT_LIBRARIES wxexpat)
set(EXPAT_INCLUDE_DIRS ${wxSOURCE_DIR}/src/expat/expat/lib)
elseif(wxUSE_EXPAT)
find_package(EXPAT REQUIRED)
endif()
I would use the *.cmake files of the 3rd party dependencies stored inside <ROOT_OF_WXWIDGETS_PROJECT>/build/cmake/lib to determine which variables I need to set if builtin is selected as the value for the respective library. Since I want to use my own I need sys (e.g. -DwxUSE_EXPAT=sys as a CMAKE_ARGS inside my wxWidgets ExternalProject) and also to pass the headers and libraries accordingly.
Given the file above one would assume that EXPAT_LIBRARIES is required. However after failing to build (yet again) and seeing that the reason was the activated expat build and that it was set as builtin I checked the log in detail and found the following error:
Could NOT find EXPAT (missing: EXPAT_LIBRARY) (found version "2.2.6")
Notice the EXPAT_LIBRARY. After passing it (-DEXPAT_LIBRARY=...) my build was complete. For me this is a bug or simply inconsistency between the dependency cmake file and the rest of the wxWidgets project.
It is important to note that I do not retrieve the external dependency through wxWidgets itself (see config.cmake and more precisely the macro wx_get_dependencies(...)). This solves the problem with a basic configuration and build of wxWidgets but if you don't want to tackle every dependency of wxWidgets on your own (why should you?), I recommend looking for a solution where the dependencies (at least the ones you don't want to deal with) are automatically retrieved, configured and build as builtin.

Related

How to build OpenImageIO 1.4.12 with VS2015

I am trying to build dependencies for a project, currently based on VS2013, with VS2015.
Most of them are building without problems, either as they are or with some patch, but I am totally at a loss with OpenImageIO 1.4.12.
I am passing parameters to cmake and msbuild that set up use of VS2015 for everything, and indeed the generated solution files indicate "vc140_xp" as the chosen toolset.
But at link time I receive error like this one, indicating that somewhere there is a reference to boost libraries built with VS2013:
LINK : fatal error LNK1104: cannot open file 'libboost_thread-vc120-mt-1_56.lib' [F:\...\deps\x64\oiio-Release-1.4.12\build\src\libOpenImageIO\OpenImageIO.vcxproj]
Of course I have a bunch of libboost_xxx-vc140-mt-1_56.lib in another place, since I've built them also with VS2015. Also dependencies set up in solution file correctly refer to libboost_xxx-vc140-mt-1_56.lib files and to the correct path, and by doing a FINDSTR in all OpenImageIO build tree I'm not able to find any reference to the older VS version.
But the same command lists a lot of .obj files containing those references, such as (put on multiple lines for better readability):
build\src\libOpenImageIO\OpenImageIO.dir\Release\xmp.obj:/FAILIFMISMATCH:"_CRT_STDIO_ISO_WIDE_SPECIFIERS=0"
libboost_regex-vc120-mt-1_56.lib
libboost_thread-vc120-mt-1_56.lib
libboost_date_time-vc120-mt-1_56.lib
libboost_system-vc120-mt-1_56.lib
libboost_chrono-vc120-mt-1_56.lib
Is it because of these references that link fails looking for different versions of boost libs? Where can these references come from? And how can I get rid of them, since apparently they are nowhere to be found in my configuration?
This problem is in boost itself, not in OpenImageIO, and is caused by the used version of boost being released before VS2015.
As pointed out by kenba in his comment, this answer points to the solution:
Visual Studio 2013 (vs120) asks for wrong boost libraries.
The full explanation, related to an older version of boost and VS, can be found here:
How do I specify, which version of boost library to link to?.
In the case of VS2015, here is how the corresponding lines of code in boost/config/auto_link.hpp should appear:
# elif defined(BOOST_MSVC) && (BOOST_MSVC < 1800)
// vc11:
# define BOOST_LIB_TOOLSET "vc110"
# elif defined(BOOST_MSVC) && (BOOST_MSVC < 1900)
// vc12:
# define BOOST_LIB_TOOLSET "vc120"
# elif defined(BOOST_MSVC)
// vc14:
# define BOOST_LIB_TOOLSET "vc140"
Implementing these lines solved my problem.

CMake - set_property could not find TARGET xxx. Perhaps it has not yet been created

Greetings, what I'm trying to do is to port an existing Windows application to Linux using CMake with CMakeLists, which I generated with the vcproj2cmake Script (https://github.com/sixman9/vcproj2cmake).
With the CMakeLists.txt and CMake I was able to successfully port a VS 2005 project to VS 2010. Now I try to port the same VS 2005 project to Linux, so that I can edit it with KDevelope.
The project itself is small and I think it would be easier to just create a new project and copy all relevant files (if that would work), the problem is, that it's not only one project but many, hence I was looking for a way to port a project in an as simple as possible way.
In Linux I was able to create a CMakeLists.txt using the vcproj2cmake script. The next step would be creating a KDevelope project using CMake. And this is where I'm stuck.
Everytime I try to run CMake I get the following error:
CMake Error at CMakeLists.txt: 196 (set_property) :
set_property could not find TARGET Test_Project. Perhaps it has not yet been
created.
Test_Project: installing /root/Desktop/Test_Project/vs8/CMakeLists. txt rebuilder (watching /root/Desktop/Test_Project/vs8/Test_Project. vcproj)
Configuring incomplete, errors occurred!
See also “/root/Desktop/Test_Project/vs8/CMakeFiles/CMakeOutput.log”.
I searched for a solution or an approach for quite a time now, but the only results that I get are project-specific, or at least I think they are.
Content of the CMakeLists.txt from line 196:
set_property(TARGET Test_Project PROPERTY PROJECT_LABEL "Test_Project")
v2c_rebuild_on_update(Test_Project "${CMAKE_CURRENT_SOURCE_DIR}/Test_Project.vcproj" ${CMAKE_CURRENT_LIST_FILE} "vcproj2cmake.rb" ".")
include(${V2C_HOOK_POST} OPTIONAL)
Perhaps there are more efficient ways to port many projects form Windows to Linux, I'm open for any suggestion.
It is a bit difficult to help without having your project - since you are using a third party tool to convert a VC project you should ask the author of that tool. :D
If you have many projects which you are going to maintain, I suggest that you select one where you can create a cross platform (Windows/Linux) CMake config for which you can reuse for other projects.
Most of the config should be the same for all platforms you are building for - the difference should be which generator is used and what libraries to link in the final executable (if you are building one that is). The generator is specified when running cmake.
In my opinion you should try an out of source build with the following structure:
/$COMMON_DIR/CMakeLists.txt
/CMakeLists.txt
/src/
/build/
/build/vcX
/build/generate_vcX.bat
/build/linux
/build/generate_linux.sh
$COMMON_DIR should contain the CMake code you expect to be common for all you projects - like a function to create a static library for a module which searches for files in /src and another function which can be used to add an executable for certain platform.
The CMakeLists.txt in the root of your project (repository, I assume) should call the functions defined in $COMMON_DIR and possibly add some project specific defines or link flags.

How to link ".a" fat-static-libs with Apportable?

How do I link ".a" fat-static-libs with Apportable?
In the beginning, I did get a warning,
Warning: Library not found for lib-name. Try adding this to the
'deps' array in the 'add_params' section of your configuration.json
file. Check ~/.apportable/SDK/System for the directory names that
correspond to 'deps' entries.
I did add it to "deps" in the JSON right where it says this:
// A list of dependencies. Typically these correspond to frameworks in the xcode project.
My library isn't a framework, though. It's just a .a static library that has armv7, armv7s, and i386 parts which I assembled using lipo from two libraries (an armv7 and armv7s .a and a i386 .a) built with Xcode. They both use a single framework which is this Boost framework.
Adding it under deps squelched that warning message, but the apportable linker is still giving undefined references, so it is still not properly linking this file.
Now I know that Apportable has to re-jitter all this stuff, since Android won't know what to do with a Mac-executable format, so it's probably got to go pick apart my library and possibly turn it into an ELF-library before final linking. I'm not sure how to go about debugging this at this point, but is this supported at all?
Since you get "library not found" that means Apportable simply can't find the file. Hence the problem is merely with the file's location (or existence) and not what's in the library or how it is built.
The most common issue with dependent targets, especially Xcode projects dropped into other Xcode projects respectively workspaces with multiple projects, is that the resulting output of each target/project goes to different folders. Then Apportable (as well as xcodebuild under some circumstances) can't find the resulting libraries.
First step you should try is to make sure that the target dependencies are set. Select the app target, go to the Build Phases pane and under Target Dependencies add all frameworks and libraries that appear in the list and that your project depends on. This should ensure that the dependent frameworks/libraries do get built - because Xcode's built-in automatic dependency resolution isn't available to command line tools from what I understand. So you need to explicitly specify the dependent projects respectively their output.
If that doesn't help, you can force all targets to write their output to the same folder. Under Build Settings for every target change the Build Products Path (symbolic name: SYMROOT) to the same folder, for example ~/myprojectsbuildoutput
That way even dependent other projects will place their output in the same folder and xcodebuild as well as Apportable (it depends on xcodebuild) will be able to find the library files.
Tip: make sure your project builds successfully on the command line. Open Terminal, cd into the folder where the .xcodeproj bundle is and enter xcodebuild. If xcodebuild fails merely due to validation, disable Validate Built Product under Build Settings of the app target. If xcodebuild fails, Apportable likely isn't going to work either because it depends on xcodebuild. So as a prerequisite make sure that xcodebuild works on your project.
If xcodebuild also gives you "library not found" try calling it with a specific SYMROOT:
xcodebuild SYMROOT=~/myprojectsbuildoutput
If that then works you know you have to update each target's Build Projects Path. From what I know it's not currently possible (or not documented) to pass custom xcodebuild parameters via Apportable, so it needs to be set up in the .xcodeproj itself.

CVTRES.exe is discarding my DLL exported functions

I'm working on a project that creates a DLL in C for Windows CE 5.0 using STANDARDSDK_500. The project is relatively simple with just one C source file. What I've noticed is that when I clean and build the project using Visual Studio 2005, it fails to create my Import lib. When I tell Visual Studio to rebuild it, it correctly creates the import lib.
Turning on verbose linking, I discover that in the failure case (clean and build) CVTRES.exe is discarding my functions, like so:
Invoking CVTRES.exe:
/machine:thumb
/verbose
/out:"C:\...\Temp\lnkC7E.tmp"
/readonly
/windowsce
".\standardsdk_500 (armv4i)\release\WLTBApi.res"
Microsoft (R) Windows Resource To Object Converter Version 8.00.50727.42
...
adding resource. type:VERSION, name:1, language:0x0409, flags:0x30, size:892
Discarded '.idata$4' from coredll.lib(COREDLL.dll)
...
Discarded WLRegisterStartupApp from WLTBApi.obj // my functions! Oh noes!
...
This discards all of my functions, which causes the linker to not create an import lib because there are no exported functions.
I figured that the input was the .res file mentioned in the commandline - WLTBApi.res. This file is identical in the intermediate directory after trying to compile both the working way (rebuild) and the non-working way (clean. build).
So, my first question is: what are the other inputs to the CVTRES.exe program so that I can find discrepencies between the two builds?
Second: what other troubleshooting techniques would you recommend?
Additional Info - I thought perhaps the .obj files were additional inputs - they differ between the builds. I now believe that they are outputs of CVTRES.exe. If anyone knows whether or not I'm correct in this, let me know.
Okay, so I found a solution, but I'm terribly dissatisfied with it. I discovered that the project I was building had a Dependency, but one that wasn't actually a dependency. In other words, the project, WLTBApi was building a DLL, and had a dependency configured, WLTBApiLib, but it wasn't actually using any of the output of that project. By removing the dependency, the problem went away.
I'd still love to know more about how to find an actual answer to what was going on, but maybe this answer will help someone else in the future.

Building Boost on Linux - library names

I am trying to build an application which depends on Boost. So I downloaded Boost 1_41_0 to my Linux box and followed the instructions found on the Boost site for Unix variants,
http://www.boost.org/doc/libs/1_41_0/more/getting_started/unix-variants.html.
They basically suggest that I run ./bjam install, which I did. The build completed successfully. However, the library names don't seem to match the Boost naming convention described both in the documentation above, and what is specified in the makefile of the application I am trying to build.
I noticed that there are a bunch of options that I can specify to bjam and I tried to play with those, but no matter what happens I can't seem to get it quite right. My understanding is that the libraries should go into the $BOOST_ROOT/lib directory. This is where the libraries show up, but named:
libboost_thread.a
libboost_thread.so
libboost_thread.so.1.41.0
I'd expect them to be named libboost_thread-gcc41-mt-d-1_41_0 or something similar.
I did try ./bjam --build-type=complete --layout=tagged and I see:
libboost_thread.a
libboost_thread-mt.a
libboost_thread-mt-d.a
libboost_thread-mt-d.so
libboost_thread-mt-d.so.1.41.0
libboost_thread-mt-s.a
libboost_thread-mt-sd.a
libboost_thread-mt.so
libboost_thread-mt.so.1.41.0
libboost_thread.so
libboost_thread.so.1.41.0
So, I am not sure if I should just make stage my -L directory? Is there any documentation which describe this in more detail?
The names was changed in 1.40.0 - see in release notes:
Build System
The default naming of libraries in
Unix-like environment now matches
system conventions, and does not
include various decorations.
They probably forgot to update this part in the build documentation.
There are two variables here. First is "install" vs. "stage" (default). "install" copies both libraries and headers into a directory -- /usr/local by default, and you can then remove source tree. "stage" puts libraries to "stage/lib", and you should add "-L /stage/lib -I " flags.
Second is --layout=versioned and --layout=system. It seems like you have discovered what they do already, and indeed, system is default since 1.40. The getting started guide fails to mention this, and I've added an action item to update it. Ideally, you should talk to the authors of the application to use the system naming of boost libraries. If that's not possible, then building with --layout=versioned is the only option.
From the Boost documentation at http://www.boost.org/doc/libs/1_35_0/more/getting_started/windows.html#library-naming, the convention is:
-mt Threading tag: indicates that the library was built with multithreading support enabled. Libraries built without multithreading support can be identified by the absence of -mt.
-d ABI tag: encodes details that affect the library's interoperability with other compiled code. For each such feature, a single letter is added to the tag:
Key Use this library when:
s linking statically to the C++ standard library and compiler runtime support libraries.
g using debug versions of the standard and runtime support libraries.
y using a special debug build of Python.
d building a debug version of your code.
p using the STLPort standard library rather than the default one supplied with your compiler.
n using STLPort's deprecated “native iostreams” feature.
For example, if you build a debug version of your code for use with debug versions of the static runtime library and the STLPort standard library in “native iostreams” mode, the tag would be: -sgdpn. If none of the above apply, the ABI tag is ommitted.

Resources