I am using MonoDevelop 2.2 from the Debian testing repository. I have installed the addins for GTK support, for version 2.8 and 2.10.
When I compile my solution, I get warnings saying Warning: Assembly 'glade-sharp, Version=2.10.0.0, Culture=neutral, PublicKeyToken=35e10195dab3c99f' not found. Make sure that the assembly exists in disk. If the reference is required to build the project you may get compilation errors. (ProCos)
The warning is perfectly alright, because the installed libraries do not offer V2.10 of glade-sharp. So I open the reference dialog, remove the reference and insert a reference to V2.8 of glade-sharp (which does exist). Close the reference dialog and recompile. And bang, same warning and the reference has been changed back to V2.10.
Anybody have any ideas how to fix this? Or is this a known bug in that version of MonoDevelop?
If you're using the GTK version support, all the GTK-related assemblies should have the same version. I suspect that if gtk-sharp.dll is 2.10, then MD will "fix" glade-sharp to 2.10 too. In project options is a dropdown for picking the GTK version; using this will update all GTK assemblies to a specific version.
Note also that you can use the project pad to set a reference to not require a specific version.
I suggest trying MD 2.4, and if it's still an issue, please file a bug report.
Related
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.
I have a project that I'm trying to get updated to the universal CRT, and I'm still seeing a dependency on vcruntime140.dll and msvcp140.dll, which I think should have been replaced with a ucrtbase.dll, as well as api-ms-win-crt* dlls.
I've already checked out this response here, and this blog post, which explain things pretty well, but still no luck. Here's what I've changed:
Platform Toolset: Visual Studio 2019 (v142)
Windows SDK version: 10.0 (latest installed version)
Additional include directories: added $(UniversalCRT_IncludePath)
Additional library directories: added $(UniversalCRT_LibraryPath_x86)
I also updated my linker dependencies to this set:
ucrt.lib
vcruntime.lib
msvcrt.lib
user32.lib
advapi32.lib
Wsock32.lib
Crypt32.lib
ws2_32.lib
But when I run dumpbin /dependents mydll.dll
File Type: DLL
Image has the following dependencies:
api-ms-win-crt-string-l1-1-0.dll
api-ms-win-crt-heap-l1-1-0.dll
api-ms-win-crt-runtime-l1-1-0.dll
api-ms-win-crt-stdio-l1-1-0.dll
api-ms-win-crt-filesystem-l1-1-0.dll
api-ms-win-crt-convert-l1-1-0.dll
api-ms-win-crt-time-l1-1-0.dll
api-ms-win-crt-environment-l1-1-0.dll
api-ms-win-crt-utility-l1-1-0.dll
VCRUNTIME140.dll
USER32.dll
ADVAPI32.dll
WSOCK32.dll
CRYPT32.dll
WS2_32.dll
MSVCP140.dll
bcrypt.dll
KERNEL32.dll
Summary
E000 .data
66000 .rdata
E000 .reloc
1000 .rsrc
14A000 .text
Is there something else I'm missing to be able to drop the dependency on the specific CRT version?
I've done some more digging, and found this page that says the following:
Starting in Visual Studio 2015, the CRT has been refactored into new
binaries. The Universal CRT (UCRT) contains the functions and globals
exported by the standard C99 CRT library. The UCRT is now a Windows
component, and ships as part of Windows 10.
Great, that's what I expected. Just below though is this:
The vcruntime library contains Visual C++ CRT implementation-specific
code, such as exception handling and debugging support, runtime checks
and type information, implementation details and certain extended
library functions. This library is specific to the version of the
compiler used.
Which implies that there is still a non-universal VC++ dependency that gets linked in by VS. To me, this implies that a dependency-free DLL doesn't really exist (at least not something built with VC++), since you'll always have a vcruntime dependency.
There is always the option of static linking (/MT), but in my case, I'm also looking at a DLL that has /clr, and the two options are mutually exclusive. Application local deployment (just copy vcruntime140.dll with the binaries) also seems to work, and may be the best option for something that I want to be a portable/xcopy deployment.
I'm going to mark this as an answer for now, but if there's a way around this, I'd be interested in seeing it.
As far as I understand, "2" in "/lib/ld-linux.so.2" changes very rarely. There are old programs that can't work with new library and new programs that can't work with the old library. But they both refer to /lib/ld-linux.so.2, preventing installing both libraries.
BTW what are that version 'GLIBC_2.17' not found things? Why version is not in soname, but somewhere else?
Whenever a library is changed in a way that old programs do not work with the new version of the library this number is chaned. If old programs will still work with the newer library (and programs needing the new version will not cause a crash with the old library) there is no need to change the number because you can simply install the latest version of the library.
As far as I understand the "2" (it was "1" ten years ago) should not change any longer. The reason is simple:
The first version of "ld-linux.so.2" was written in a way that any version of "ld-linux.so.2" should work with any program using this file - maybe printing an error message when an older version of "ld-linux.so.2" is used.
This means: It is never necessary to install two different "ld-linux.so.2" files but it is enough to install the latest version of this file. You should not simply overwrite this file because it comes as a bundle with other files (e.g. "libc.so.6") that must have the same version.
In the "2" version of the loader .so files may contain a table of version numbers supported. So "libc.so.6", version GLIBC_2.16, may contain the information that "GLIBC_2.15" is also supported by this version of the library. (New versions should be backward compatible so this should be the case.)
Programs may contain a list of versions required (for example: a program requires libc.so.6 version "GLIBC_2.17"). The loader (ld-linux.so.2) checks if the library supports the version that is required by the program and refuses starting the program if not. In this case the error message form your question is printed by the loader.
Hi I have an XCode project which is ARCd but uses some 3rd party (AFNetworking) classes which are not ARCd. I have specified the -fno-objc-arc flag against these files however when I run scan-build I get a number of errors such as:-
error: 'autorelease' is unavailable: not available in automatic reference counting mode
I can see that scan-build is using -fobjc-arc when compiling / checking these classes which is incorrect.
Please could someone advise how I can get scan-build to pick up the correct settings?
FYI I am using checker-267 version downloaded from http://clang-analyzer.llvm.org/
Many thanks
Raised this with the clang team at Apple and they swiftly came back to say that this is a known bug, see:
http://llvm.org/bugs/show_bug.cgi?id=13683
A new version of the checker should be released soon to fix this.
I'm having a weird problem when trying to register the .dll i created using regsvr32.
During development everything went fine, the debug version registers and works fine. Now i wanted to create a Release version, but that Version does not register anymore.
regsvr32 comes up with the following error:
The module "mpegsplitter.dll" failed to load.
Make sure the binary is stored at the specified path or
debug it to check for problems with the binary or
dependent .DLL files.
The specified procedure could not be found.
Some research brought me to the dependency walker, which does tell me this
Error: At least one module has an unresolved import due to a missing export function in an implicitly dependent module.
It also does show a dependency on "crtdll.dll" that the debug version does not have (The function view shows soem functions that normally should be in ole32.dll), which is colored red'ish.
So far so good, i guess its somehow related to what the dependency walker shows there.
But where do i go from here? How do i fix it?
Any help would be greatly appreciated, that has been keeping me busy for several hours already.
Thanks!
I have the same problem. When I compared the different between "Command Line" (in Project Properties -> Linker) of Release and Debug mode, I found out that the "Optimization" options (in Project Properties -> Linker) of Release mode was turned on while ion Debug not.
Turning of Optimization for linker in Release mode solved the problem
Is it possible that the debug version is compiled with _ATL_MIN_CRT but the release version isn't? You can set this with the Minimize CRT Use in ATL project property as well.
I fixed it. It was actually being caused by the order of some mingw libraries i included to link against ffmpeg. Oh well, how weird.
In my case, the difference was in Module Definition File entry between DEBUG and RELEASE. The DEBUG version was pointing to the .DEF file where as the RELEASE had it empty.