I want wrap Scintilla in Delphi/FreePascal component and Java JNI. My doubts:
After compiling source under Windows, it create two libraries: SciLexer.dll (~960 KB) and Scintilla.dll (~460 KB) which library I must use?
Libraries have only one function: Scintilla_DirectFunction, which is never called in examples.
In examples (dmapp.zip and How to start a project with Scintilla?) is ::LoadLibrary("SciLexer.DLL"); but never is remembered handle of this library! Only is created some window and sendmessages. How it works?
SciLexer.dll contains all the lexers(under scintilla\lexers), while Scintilla.dll does not.
Check this out:http://www.scintilla.org/Steps.html
Related
The question is for example I have my.binary that depends on 1.so that depends on 2.so that depends on 3.so.
When doing 'ldd 1.so', it only shows that it depends on '2.so', so will my.binary execute if '3.so' is missing but not a function is called from '3.so'? Basically '3.so' is shipped with my.binary, but during some runtime checks, it is not used under certain condition.
I do see sharedlibrary not found error if 2.so does not exist..
No, this functionality is called lazy loading and is not supported by Linux shared libraries. You can work around this by manually loading library via dlopen/dlsym instead of directly linking to it.
While not specifically related to Frida's use of V8, I was reading this Frida release page and noticed it made the following reference:
Short of writing the whole agent in C, one could go ahead and build a
native library, and load it using Module.load(). This works but means
it has to be compiled for every single architecture, deployed to the
target, etc.
The comment by Ole alludes to this being possible, though I can't find any references other than the NodeJS C++ Addons features that are, of course, specific to NodeJS (though NodeJS does use V8).
tl;dr
How does one load a generic object such that all of its exported functions are callable from Javascript? Is this possible?
I was misinterpreting the context of the comment in the original link, it seems. I was under the impression that Module.load was a v8-ism, while it in fact appears to be a Frida-API.
https://frida.re/docs/javascript-api/#module
I figured this out about the time I was writing code to use Module.getExportByName to just pass the addresses of dlopen and dlsym to the entry of my CModule code.
I have asked this question on linux, but now I need the same info on macos... The question is (adapted to macos):
I am trying to create a shared library, libbar.dylib, that embeds a commercial static library (licensing is fine). The commercial library has 4 versions: libfoo-seq.a, libfoo-mt.a, libfoo-seq.dylib, and libfoo-mt.dylib (they all provide the same symbols, just the code is sequential/multi-threaded, and the lib is static/shared). Of these four I want my code always to use the sequential foo library, so when I create libbar.dylib I link together my object files and libfoo-seq.a.
The problem is that the users of my library may have already pulled in libfoo-mt.dylib by the time they pull in my libbar.dylib, thus all symbols from libfoo are already present by the time libbar.dylib is read in, so my calls to the functions in foo are resolved to the multithreaded version. At least I think this is happening. Is there any way to double check?
If this is really what is happening, I wonder how can I resolve this issue? What kind of magic flags do I need to use when I compile to create my object files and when I link my object files with libfoo-seq.a to create libbar.dylib?
I'm learning ESP-IDF platform and now want to create a library in order to be able to structure my code properly in the future.
I've done some research and found few things, for instance a library that could be as an example. The only issue with it being too large, I can't clearly see what's the bare minimum for the simplest library code.
What is the minimum configuration for an ESP-IDF static library that can be built into a .a file?
A minimal ESP-IDF component would have an empty component.mk file, C/C++/ASM source file(s), and header file(s) in include subdirectory. At build time, all source files of the component will be compiled and then linked into a static library, which can be found in build/component_name/libcomponent_name.a. This is further explained in ESP-IDF build system documentation.
There are a few such simple components in the ESP-IDF itself, e.g. log.
I'm still not 100% sure with the framework linking process, but from what I've seen here before nobody has asked a similar question, perhaps because this could be a silly question, but I'll give it a go anyway.
In my current X-Code project, I'm using a custom framework, say example.framework. At the moment, as far as I'm aware of, in order for the program to function with the framework, I need to have it either in /Library/Frameworks, or I need to have it copied into the bundle resources in the build phase.
Would anybody know about adding a framework to a project in a way that it gets compiled into the executable, so I don't have to include the raw framework with the app? I'd rather not share the whole framework...
Thank you in advance! Any suggestions are also welcome!
A Mac OS X framework is basically a shared library, meaning it's a separate binary.
Basically, when your main executable is launched, the OS will load the framework/dylib into memory, and map the symbols, so your main executable can access them.
Note that a framework/dylib (bundled into the application or not), does not need to contain the header files, as those are only needed at compilation time.
With Xcode, you can actually decide whether or not to include the header files, when you are copying the framework to its installation directory (see your build phases).
If you don't copy header files, people won't be able to use your framework/dylib (unless they reverse-engineer it, of course).
If you still think a framework is not suitable for your needs, you may want to create a static library instead.
A static library is a separate object file (usually .a) that is «included» with your final binary, at link time.
This way, you only have a single binary file, containing the code from the library and from your project.