I'm trying to add Detox e2e testing to my project, and when I run the assembleAndroidTest I get proguard warnings that fails the build:
Warning: library class android.content.Intent depends on program class org.xmlpull.v1.XmlPullParser
Warning: library class android.content.IntentFilter depends on program class org.xmlpull.v1.XmlSerializer
Warning: library class android.content.IntentFilter depends on program class org.xmlpull.v1.XmlPullParser
Warning: library class android.graphics.drawable.BitmapDrawable depends on program class org.xmlpull.v1.XmlPullParser
Warning: library class android.graphics.drawable.Drawable depends on program class org.xmlpull.v1.XmlPullParser
Warning: library class android.graphics.drawable.Drawable depends on program class org.xmlpull.v1.XmlPullParser
Warning: library class android.graphics.drawable.Drawable depends on program class org.xmlpull.v1.XmlPullParser
Warning: library class android.graphics.drawable.Drawable depends on program class org.xmlpull.v1.XmlPullParser
Warning: library class android.graphics.drawable.Drawable depends on program class org.xmlpull.v1.XmlPullParser
Warning: library class android.graphics.drawable.Drawable depends on program class org.xmlpull.v1.XmlPullParser
Warning: library class android.util.Xml depends on program class org.xmlpull.v1.XmlPullParser
Warning: library class android.util.Xml depends on program class org.xmlpull.v1.XmlSerializer
Warning: library class android.util.Xml depends on program class org.xmlpull.v1.XmlPullParser
Note: there were 13 unresolved dynamic references to classes or interfaces.
You should check if you need to specify additional program jars.
(http://proguard.sourceforge.net/manual/troubleshooting.html#dynamicalclass)
Note: there were 39 accesses to class members by means of introspection.
You should consider explicitly keeping the mentioned class members
(using '-keep' or '-keepclassmembers').
(http://proguard.sourceforge.net/manual/troubleshooting.html#dynamicalclassmember)
Warning: there were 89 unresolved references to classes or interfaces.
You may need to add missing library jars or update their versions.
If your code works fine without the missing classes, you can suppress
the warnings with '-dontwarn' options.
(http://proguard.sourceforge.net/manual/troubleshooting.html#unresolvedclass)
Warning: there were 16 instances of library classes depending on program classes.
You must avoid such dependencies, since the program classes will
be processed, while the library classes will remain unchanged.
(http://proguard.sourceforge.net/manual/troubleshooting.html#dependency)
Couldn't find any dontwarn that suppressed it and allowed me to build the project, This SO thread didn't worked either.
Thanks
Related
I have a library that gets build and depends on other libraries:
add_library(library1 STATIC main.c)
target_link_libraries(library1 m;pthread)
If I want to now use the just declared library1 in other library I would expect that libm and libpthread to be passed in the linker to build library2
add_library(library2 STATIC main2.c)
target_link_libraries(library2 library1) # I would expect m and pthread to be linked to library2 but don't
add_executable(binary library2)
Is the normal behavior pass libm and libpthread to the compiler to build binary?
Thanks
I'm building a dll in D with some utils, tools, ect. I can successfully compile a basic dll and test program to use it in visual D without any issues. I am familiar with the process of creating and using dll's. Especially statically linking against them. But if a module in the dll has a static this(), or imports a module with a static this(), the dll will compile, but any program you build that uses it will fail with a foo.bar.__ModuleInfo being unresolved.
error LNK2001: unresolved external symbol "dtoolbox.dtoolboxdllmain.__ModuleInfo" (__D8dtoolbox15dtoolboxdllmain12__ModuleInfoZ)
In this case my dllmain module dtoolbox.dtoolboxdllmain imports core.runtime which has a static this() so i get this error. How do i resolve this? What are static module constructors doing to cause this? As long as there are no static constructors everything works fine.
[edit] Importing core.runtime wasn't the problem, it was the modules own static this(), not core.runtime's static this().
The solution is to refrain from importing a module with the dll's static this() && static ~this() into a module of a program which uses the dll. (In this case the dllmain module was being imported, for no reason at all, my mistake) Not to say that the dll can not have them though, they just need to be there in some file when compiling the dll. I found it convenient to write them in the same module as your dllmain as this file will never really need to be referenced/imported by a program using the dll.
I have legacy c++ code that I'm trying to re-engineer.
I want to take some part of code out of the project as a ".so" shared library and load them dynamically by "dlopen".
I have written a dynamic loading mechanism which can load new modules dynamically at runtime.
Now I want to decouple existing modules from main project.
For instance I have extracted module "X" from the main project and created shared library which can be loaded later, but some part of the main project are using module X's classes directly and I can't change them yet.
I can compile the project by using module X's header files, but linker throw out "undefined reference" error.
How can I tell c++ linker that these classes will be added later by dlopen mechanism at runtime?
note: I can link and run project by copying created ".so" file of module X in "/lib" folder and use it when linking by "-lX" flag, but if I delete this file form the /lib folder the project fails on startup.
I know if you use X's classes directly you have to link X.so to your program. But if you link X.so you can use dlopen in runtime.
What you need is called an import library. They contain small wrappers for all necessary functions and thus satisfy all static linker dependencies. At runtime these wrappers will load dynamic library if it's not yet loaded and forward execution to real implementation inside library.
Import libraries is a standard feature of Windows DLLs but they are not available out-of-the-box on Linux (or any POSIX system). You can implement wrappers by hand or use Implib.so to generate them automatically.
I'm creating a framework that links against a static library using the linker flags -pagezero_size and -image_base
The library is LuaJIT compiled for 64 bits on Mac OS X, and my framework is just an ObjC wrapper for LuaJit plus a bridge to load other frameworks and passing classes and instance objects back and forth.
Everything works fine, but now I want to start writing tests for my framework before I start making some modifications, but the problem is that Xcode complains that pagezero_size is only for the main executable. i.e. adding the flags to the test target throws the error:
ld: -pagezero_size option can only be used when linking a main executable
Any ideas how to run tests for a static library that needs to be linked using -pagezero_size and -image_base?
The title mostly covers it, what is the difference between a module and a shared library? I just found this distinction in CMake's add_library command, where they say:
SHARED libraries are linked dynamically and loaded at runtime. MODULE libraries are plugins that are not linked into other targets but may be loaded dynamically at runtime using dlopen-like functionality.
But I can load a shared object using dlopen(), can't I?
The difference is that you can link to a SHARED library with the linker, but you cannot link to a MODULE with the linker. On some platforms.
So... to be fully cross-platform and work everywhere CMake works, you should never do this:
# This is a big NO-NO:
add_library(mylib MODULE ${srcs})
target_link_libraries(myexe mylib)
To be fair, on Windows, they're both just dlls, and so this code might actually work. But when you take it to a platform where it's impossible to link to the MODULE, you'll encounter an error.
Bottom line: if you need to link to the library, use SHARED. If you are guaranteed that the library will only be loaded dynamically, then it's safe to use a MODULE. (And perhaps even preferable to help detect if somebody does try to link to it...)
I think the distinction being made is that shared libraries are specified by the developer at compile-time and must be present for the application to run, even though their methods are loaded at runtime. A module, i.e. plugin, adds additional support at runtime but isn't required. Yes, you can dlopen() a shared library but in that case it would not have been specified as a required part of the program and functions instead as a module.
Another difference is in how ..._OUTPUT_DIRECTORY and ..._OUTPUT_NAME are handled:
Module libraries are always treated as library targets. For non-DLL platforms shared libraries are treated as library targets. For DLL platforms the DLL part of a shared library is treated as a runtime target and the corresponding import library is treated as an archive target. All Windows-based systems including Cygwin are DLL platforms.
For example, this means that if you compile a SHARED library on Windows, LIBRARY_OUTPUT_DIRECTORY will be ignored, because it's looking at ARCHIVE_OUTPUT_DIRECTORY and RUNTIME_OUTPUT_DIRECTORY instead.