I'm writing Rust bindings for a cross-platform C++ library and I'm having problems building my example applications on Windows that consume this library as a dependency, because there's a mismatch in the debug settings between the application and the dependency.
Specifically, the error I'm getting is error LNK2038: mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '2' doesn't match value '0' in {libfile}, which I can avoid if I compile my example app with --release config, as it matches what the dependency is being built with.
Is there a way I can force dependency libraries to be built with the same settings as the main application, ideally in a way that's completely transparent to the user?
I tried looking for some rustc flags that could help me here, but I couldn't find anything relevant: https://doc.rust-lang.org/cargo/reference/build-scripts.html#rustc-flags
Related
When running the package phase in maven, I get the following warning after the javadoc has been generated:
javadoc: warning - The code being documented uses modules but the packages defined in http://docs.oracle.com/javase/7/docs/api/ are in the unnamed module.
What does this mean?
Something similar happened to me. I got the following error message when employing the maven-javadoc-plugin.
[ERROR] javadoc: warning - The code being documented uses modules but the packages defined in http://docs.oracle.com/javase/7/docs/api/ are in the unnamed module.
I had copied and pasted example xml into my POM verbatim which employed version 2.9.1. When I updated to the current version (currently 3.4.0) this error went away.
IDK if you are using this plugin. If so, check the version. If not, perhaps you can troubleshoot your plugins to determine which, if any, are triggering this error message. If there is a specific culprit, check that it is a current version.
My project is set to compile at a compatibility level for Java 11. I don't have any references to Java 1.7, AFAIK. I've run across various situations using Maven where older versions of Java are the default, so I think in any configuration situation that allows you specify a Java version, it's maybe safest to simply go ahead and do so, even if it is optional.
Today, I ran into a runtime NoSuchMethodError caused by a guava dependency conflict:
One of my third-party dependencies, let's call it A, invokes HostAndPort.getHost(), which is defined in some guava version between (18.0, 23.6-jre]. A depends on guava:23.6-jre, so it's compiled without any problem. But I have another dependency, let's call it B, depend on guava:18.0, and unfortunately according to the rule of "nearest wins", maven choose guava:18.0.
Everything works fine while compiling and packaging, but the devil comes out in runtime, causing my program to crash, which is bad.
So, I wonder is there any way I can detect this kind of problem using tools like maven, so that I can fix them before launching my program?
I am trying to prevent dependency checking in java compiler, I use command line compilation,is there any way to tell javac compiler not to check dependency while compiling a java file ?
... is there any way to tell javac compiler not to check dependencies while compiling a java file ?
The simple answer is No.
Suppose you have some class A that wants to call some method m defined by class B. In order to successfully compile A, the compiler needs to know that B is a real class, that it defines the method m, that it has the expected number and type of arguments, what checked exceptions it throws, and what type of value it returns. Without this information about B, the compiler cannot compile A.
And this propagates to the project level. If a class in project P depends on a class in project Q, the compiler must have that class (at least) in order to compile the class in P.
In short, no such compiler option exists, and it is hard to see how it could be implemented it it did.
If you're two projects are dependent on each other then they are really one project and must be built together. If the relationship is a one-way relationship then you will still need to build the dependent project first and then have the results of the project on the classpath when building the second project.
Most IDEs have capabilities to manage this. In Eclipse you can mark that one project depends on another project and the dependent project's output files will be added to the classpath of the other. Typically all dependencies are built and packaged as jars and those jar files are placed onto the classpath when compiling parent projects.
Building code without having access to the dependencies is very difficult and not recommended. In some cases it can be possible. Eclipse has built their own incremental Java compiler so that they do not have to recompile the entire project each time a single file is modified. You can read more about it here but in order to use such a compiler you will likely have to do a lot of work.
UPDATE to reflect your new edit:
In order to build a common library that common library must not depend on any classes in your platform-specific sections. As Peter Rader has mentioned the typical way of doing that is by using interfaces. For example, your common library can have an EventListener interface which receives events. In your platform specific libraries you can implement that interface and process the events according to the specific platform. Since your common library only depends on the EventListener class and not the specific implementations it does not need those specific classes when it compiles.
If you have dependencies, they will always be checked and give warnings, but your classes will be compiled anyway.
Often frameworks offer an api.jar that contains interfaces and enums.
I don't understand the difference between these Xcode features.
I'm building and app - but the functionality of the app is being abstracted into libraries (so they can be distributed separately as an "SDK").
So I have a workspace of library projects and the app project. I can add library projects to the app project by doing "link binary with libraries". This gives me a list of .a library projects in the current workspace which I can link to.
I can also add frameworks here.
In the "target dependencies" bit all I can add is other targets in the current project.
What I really want to do is both - I want my app project to build all the other library projects when I build it. I also want to make it verbose what libraries the app (and other libraries) depend on.
So can somebody please explain the difference, and whether what I am doing is the right way to go about it?
Many thanks!
It says here...
Drag your framework product (located in the Products folder) to the existing Link Binary With Libraries build phase of your application
target. This causes the application to link against your framework.
And...
In the General tab of the inspector window, add your framework as a dependency for the application. Adding this dependency causes Xcode to
build the framework target before building the application target.
The build dependency you establish in the application target causes
the framework to be built before the application. This is important
because it guarantees that a built version of your framework will be
available to link against and to embed in the application. Because of
this dependency, you can set the active target of your Xcode project
to your application and leave it there.
So it seems that you're supposed to use both. Seems redundant though, because if you're linking to a framework then its a dependency. I suppose you might want to only link to a library and not build it first. Although Xcode seems to build linked libraries even without them being added to the dependency section. Perhaps that's a result of the "Find Implicit Dependencies" option in a scheme's build settings.
I do something similar and was explicitly setting the 'header search path' and 'library search path' in the final executable target. However this all depended on where the objects were being generated. Initially I had set this to be within the source tree (actually a sibling directory called build), however after changing the location of the Xcode DerivedData directory and telling it to build into that directory, the projects no longer built.
The final solution was simply to remove the explicit setting of the 'header/library search path' and set the target dependencies correctly. This resulted in the project building for debugging and archiving without issue.
I have a minor problem. Whenever I try to build my project using the distribution configuration it complains that one of my libraries is missing
ld: library not found for -lTouchCustoms
This only appears in distribution mode. The only difference between the release and distribution build is in the code signing section. Because of this I had to use the release build (with distribution profile code signing) to publish my app because that builds correctly, and was acceppted. If I delete and recreate the distribution config, duplicating the release config, I get the same error. How do I solve this? Thanks.
The problem is that the static library doesn't have the "distribution" build configuration. It will default to building the Release configuration instead. When the linker is trying to bring everything together, it is unfortunately looking in the "distribution-iphoneos" folder for the library while the library is actually in the "Release-iphoneos" library.
I'm trying to find a general solution for this issue in this question. For you and others it should suffice to simply add the same configuration to all static libraries you're linking against as well.