I want to make some bugfix in mono.
I have mono installed on my openSuse and download mono source code from github.
Then i want build System.Configuration project with this command:
xbuild System.Configuration-net_4_5.sln
and recieve 31 Errors, most of them like this
error CS0518: The predefined type 'System.Object' is not defined or imported
Also i recieve following warning:
warning : ProjectReference '..\corlib\corlib-net_4_5.csproj' not found, neither by guid 'some guid' nor by project file name 'path to project'
This project does exist in this location.
What's wrong?
Thanks.
You have to make the code change and then recompile the whole Mono following the instructions on how to compile Mono from source code. You cannot build individual projects, as the referenced projects cannot be resolved by 'xbuild' correctly.
Related
Our Android application consists of 40-some Android Library Modules (ALMs), each of which also builds a C++ shared library with externalNativeBuild and CMake. So far we had the dependencies between these libs set up like this:
The dependent ALM references the dependency ALM with api project(':lib')
The dependent CMake script references the dependency .so with add_library(SHARED IMPORTED lib) and set_target_properties(lib PROPERTIES IMPORTED_LOCATION ...) and a relative path.
Recently we had to upgrade to the latest Android API version. This started off a cascade because now we were getting deprecated warnings in code generated by the navigation-ktx library, but upgrading that requires upgrading Gradle and the Android Gradle plugin. After that I started getting errors like liblib.so, needed by 'project', missing and no known rule to make it.
It looks like the latest Gradle parallelizes build tasks more heavily, and this means the dependent CMake/Ninja builds are being started concurrently with their dependencies, resulting in this error because the dependency is not yet built. I figured out that what we were doing was not entirely supported, but there is a "supported" way to do that now, so I refactored our entire build to use Prefab.
Now I started getting other errors, alternating between:
1.
C++ build system [prefab] failed while executing ...
Usage: prefab [OPTIONS] PACKAGE_PATH...
Error: Invalid value for "PACKAGE_PATH": Directory ... is not readable.
ld: error: undefined symbol ...
I looked into build/intermediates and found that in the 2nd case, the cmake config script was generated incorrectly: instead of add_library(lib::lib SHARED IMPORTED ) it had add_library(lib::lib INTERFACE IMPORTED) like it it was a header only library, and there was no IMPORTED_LOCATION set in the file.
What am I doing wrong and what should I do to unbreak our build?
It looks like the toolchain support for prefab interdependencies within a project is not quite finished. Others are reporting the same kind of errors at https://issuetracker.google.com/issues/265544858:
This appears to be a race condition with generating prefab cmake files.
It says in https://issuetracker.google.com/issues/221231432 that the header-only cmake config is generated to satisfy Android Studio's IDE features (completion, etc.) before the library is actually built.
Treat as-yet-unconfigured modules as if they are Header-only libraries for Android Studio purposes. This works because Android Studio doesn't care about linker flags for the purposes of providing language services.
I'm a *nix user, installing LLVM is easy for me, just download the precompiled file, set LLVM_DIR, and you're done. But I'm having a lot of problems with Windows ...
I downloaded LLVM-<version>-win64.exe from the GitHub release, but I can't find LLVMConfig.cmake file. Then I tried to compile LLVM from the source following this documentation.
When I started compiling my own project, I got this error:
'C:/<...>/Debug/libLLVMSupport.lib', needed by '<...>.exe', missing and no known rule to make it
I guess maybe I'm missing some compile options. but I can't find the documentation for LLVM_ENABLE_PROJECTS or BUILD_SHARED_LIBS, not even a list of component names.
I tried to add -DBUILD_SHARED_LIBS=ON but CMake told me BUILD_SHARED_LIBS option is not supported on Windows.
I am trying to get a project running that is using dynamic openCASCADE libraries.
So first i set up a minimal test project using the following CMake file:
...
include_directories(/home/user/occt/build_r/include/opencascade/)
add_executable(testOCCT
main.cpp
step2stl.cpp
)
find_package(OpenCASCADE REQUIRED NO_DEFAULT_PATH)
set(OCCT_LIBS TKMesh; TKSTEP; TKSTL; TKXSBase; TKernel)
target_link_libraries(testOCCT ${OCCT_LIBS})
This is working as it should.
Now i want to link the same libraries to another library that is used in a larger project.
For the project there are 3 CMake files, one for the project and two subdirectory, one for the executable one for the myLib, which are added by add_subdirectory().
In the CMake file for myLib which is inside one of the subdirectories I've added:
...
include_directories(/home/user/occt/build_r/include/opencascade/)
...
add_library(${MY_LIB_NAME} SHARED ${my_sources})
find_package(OpenCASCADE REQUIRED NO_DEFAULT_PATH)
set(OCCT_LIBS TKMesh; TKSTEP; TKSTL; TKXSBase; TKernel)
target_link_libraries(${MY_LIB_NAME} ${OCCT_LIBS})
so basically the same as in the test project.
However now I get an error (at runtime):
symbol lookup error: myLib.so: undefined symbol: _ZN24BRepMesh_IncrementalMeshC1ERK12TopoDS_Shapedbdb
Ok, so i found the problem myself. The reason it did not work was not because of CMake, but that there was some other version of the libraries installed over the packet manager, which then got loaded instead of the right one.
purging those libs solved the problem.
However what I still don't get is why it loaded the correct library version on the test project and the wrong on the other (both tested on the same machine)
While building a new Rust "Project from other sources", in Intellij IDEA 2017, I was unable to run the project through its UI.
C:/Users/sjsui/.cargo/bin/cargo.exe run error: a bin target must be
available for cargo run
Process finished with exit code 101
I noticed that no --bin target was provided by my build configuration so I placed the path to the projects target folder; same result.
C:/Users/sjsui/.cargo/bin/cargo.exe run --bin C:\Users\sjsui\exercism\rust\hello-world\target\debug
error: no bin target named C:\Users\sjsui\exercism\rust\hello-world\target\debug
I tried creating a fresh Rust project through the Cargo command line interface, and received this error when running it:
error: could not exec the linker link.exe: The system cannot find the file specified. (os error 2)
note: the msvc targets depend on the msvc linker but link.exe was
not found
note: please ensure that VS 2013 or VS 2015 was installed with the
Visual C++ option
Evidently I must install Visual C++ build tools 2017 and am in the process of doing so. Are these errors related, or different issues?
By default, Cargo will consider the file src/main.rs to be the main binary target for the package. If this file doesn't exist, and there are no other binary targets defined in Cargo.toml, you'll get this error.
According to the documentation, when you create a Rust project in IntelliJ IDEA, you get an option to Use a binary (application) template. This should give you a src/main.rs instead of a src/lib.rs (which is the default root file for a library target). Using Cargo on the command line, you can also create an application package with cargo new hello.
Cargo defaults to --bin to make a binary program. To make a library, we'd pass --lib.
When you use --bin on the cargo run command, the argument refers to one of the [[bin]] sections in Cargo.toml, or files following the pattern src/bin/*.rs (the argument replaces the *) if there are no [[bin]] sections in Cargo.toml. For example, cargo run --bin foo will either compile and run src/bin/foo.rs or the [[bin]] section with name = "foo" in Cargo.toml.
I was trying to install a neural networks toolbox called CarlSim using visual studio 2012, in which they use gtest in their code. I try to install gtest by downloading it online and build using gtest.sln file. It gives me two warnings. I guess these two warnings are the reason for this error. But I don't know how to solve this. The gtest seems only can build gtestd.lib.
Below is the error during install of the neural network toolbox
Error 2 error LNK1104: cannot open file 'gtest.lib' C:\Users\Dukerama\Desktop\CarlSim\carlsim\test\LINK carlsim_tests
Below are the warnings of the gest.
1>------ Rebuild All started: Project: gtest, Configuration: Debug Win32 ------
1> gtest-all.cc
1>C:\Program Files(x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppBuild.targets(1299,5): warning MSB8012: TargetPath(C:\Users\Dukerama\Desktop\gtest\gtest- 1.6.0\msvc\gtest/Debug\gtest.lib) does not match the Library's OutputFile property value (C:\Users\Dukerama\Desktop\gtest\gtest-1.6.0\msvc\gtest\Debug\gtestd.lib). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Lib.OutputFile).
1>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppBuild.targets(1301,5): warning MSB8012: TargetName(gtest) does not match the Library's OutputFile property value (gtestd). This may cause your project to build incorrectly. To correct this, please make sure that $(OutDir), $(TargetName) and $(TargetExt) property values match the value specified in %(Lib.OutputFile).
1> gtest.vcxproj -> C:\Users\Dukerama\Desktop\gtest\gtest-1.6.0\msvc\gtest/Debug\gtest.lib
========== Rebuild All: 1 succeeded, 0 failed, 0 skipped ==========
Output from build command in VS you have posted suggests that there are inconsistencies between certain values in VS project properties for gtest (located in 'Configuration Properties -> General' and in 'Configuration Properties -> Librarian -> General'). However, output also suggests that the gtest library is built at location:
C:\Users\Dukerama\Desktop\gtest\gtest-1.6.0\msvc\gtest/Debug\gtest.lib
You should take this file and place it in directory where CarlSim toolbox expects to find the gtest library. You can find this out in the VS project properties for CarlSim ('Configuration Properties -> Linker -> General -> AdditionalLibraryDirectories').
P.S.
Make sure that both gtest and CarlSim link to the same runtime library, or you'll get more linker errors. You can inspect the runtime library in their VS project properties at 'Configuration Properties -> C/C++ -> Code Generation -> Runtime Library'.
I had the same problem.
Unfortunately, the proposed solution didn't help me.
In my case, the build worked properly on my PC, but it gave the error on a collegue's PC.
We solved it moving the project in a new location with a shorter path.