I'm trying to build an old application that depends on fftw. It was written against fftw2 and I am currently on fftw3 (specifically 3.3.8). It fails to link because of undefined reference to fftw_create_plan and fftw_one. Indeed, my libfftw does not have those functions anymore; the following returns nothing:
readelf -s /usr/lib/libfftw3.so | grep 'fftw_create_plan\|fftw_one'
It looks like the api has changed significantly since the code was written. Is there a compatibility layer I can use or should I just go learn fftw3's new interface?
You cannot link an FFTW2 code against FFTW3 libraries, as you are coming to realize yourself. There is also no complete interface between the two, cause the apis are really not compatible.
Having said that, you may of course link your code against FFTW2 libraries. You still can obtain them. Why is that not an option?
Related
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.
https://webassembly.studio/ allows inspection of WebAssembly (WASM) files and the corresponding SpiderMonkey-generated x86 code. I'd like to similarly inspect instructions generated by V8's WASM compilers (Liftoff and TurboFan).
I'm entirely unfamiliar with V8's codebase/API (I compiled & linked it and followed some tutorials, though). There seems to be a v8::CompiledWasmModule class available, but it does not seem to expose access to generated x86/x64 instructions by either Liftoff or TurboFan.
WebAssembly - adding a new opcode describes the process of adding a WASM opcode to V8. Seemingly appropriate functions for WASM compilation/execution are available in the mentioned classes. Though, these seem rather deeply layered within the V8 codebase and would be difficult to access were I to link V8 as a library. Also, I'm unsure if this corresponds to Liftoff or TurboFan.
Could anybody familiar with the V8 codebase give me some pointers as to how I can access Liftoff and/or TurboFan's WebAssembly compilation module, as to obtain x86/x64 code?
To inspect generated code, you can run the d8 shell with the --print-wasm-code flag. You'll need either a debug build, or a release build with the v8_enable_disassembler = true GN arg.
There's no existing way to retrieve generated code via V8's API; so if that's what you want, then you'd have to add it. Keep in mind that V8 is not designed to be a standalone compiler, which means generated code assumes that it's going to run "inside V8", so if you wanted to use it for anything else, you'd have to make significant modifications.
I've been writing a Python extension use the Python/C API to read data out of a .ROOT file and store it in a list of custom objects. The extension itself works just fine, however when I tried to use it on a different machine I ran into some problems.
The code depends upon several libraries written for the ROOT data manipulation program. The compiler is linking these libraries dynamically, which means I cannot use my extension on a machine that does not have ROOT installed.
Is there a set of flags that I can add to my compilation commands to make these libraries statically linked? Obviously this would make the file size much larger but that isn't much of an issue providing that the code runs at the same speed.
I did think about collating all of the ROOT libraries that I need into an 'archive' file. I'm not too familiar with this so I don't know if that's a good idea or not.
Any advice would be great, I've never really dealt with the static/dynamic library issue before.
Thanks, Sean.
I am accustomed to linking against libGL.so on most Linux distributions. Either mesa's implementation or NVIDIA's. However, I would really like to limit myself to OpenGL ES 2.X functionality, so I am attempting to link against and use libGLESv2.so. However, I see that glX functions are not present in libGLESv2.so dynamic section:
nm --dynamic /usr/lib64/nvidia/libGLESv2.so | grep glX
Also attempting to link agains libGLESv2.so results in undefined references to glX functions.
This leads me to my question. What is the correct way to "GetProcAddress" while dynamically linking against libGLESv2.so? Also how do you construct the appropriate context without glX?
I'm not sure how easy this will be for you to figure out and how relevant for your applications but in pi3d we get the drawing context using libEGL.so (or libegl.dll from ANGLE on windows).
This where the dynamic libraries are found and loaded
https://github.com/tipam/pi3d/blob/master/pi3d/constants/init.py
and this is where the surface is created and attached to the GLESv2 functions
https://github.com/tipam/pi3d/blob/master/pi3d/util/DisplayOpenGL.py
My project is using ACE library, and need link another library libsdk.so, it's using another version ACE library.
The link order like : ...-lMyAce -lsdk -lAnotherAce
When application running, libsdk.so called method in MyAce(I checked the core dump), and the application crash.
If I change link order to: ...-lsdk -lAnotherAce -lMyAce
My code called method in AnotherAce, it's also crash.
If I only link my ACE, it's crash. There are some link error if only link AnotherAce.
Let the libsdk.so call its ACE library, and my code call my ACE library.
How can I resolve the problem?
The Solaris linker has an option that may help, though really redesigning your application to not need two sets of libraries with the same names in the same program
is going to be the best solution.
Direct Bindings record in each library or program which library it found a symbol in, so if libsdk.so is built with -B direct -lAnotherAce, it will record each of its references go to AnotherAce, not MyAce. You'd then link your code with -B direct -lsdk -lMyAce (do not include -lAnotherAce, as the libsdk dependencies take care of that), and your code would record that it's calls to to MyAce.