0

Is there a way to add custom suffix to fftw 3.3.8 functions (besides the precision suffix)?

For example fftwMySuff_malloc instead of fftw_malloc, fftwMySuff_plan instead of fftw_plan etc.

I am compiling the library on ubuntu 16.04 using: ./configure && make && make install

Benny K
  • 1,957
  • 18
  • 33
  • What do you mean by "add custom suffix"? What is a "precision suffix"? Why would you want to do that? What have you tried, what research did you do? You can go through the source code and change each function name, did you try that? – KamilCuk Sep 03 '19 at 08:21
  • the precision suffix is just a suffix added to the **compiled libraries** (e.g., `libfftw3f` for single precision, I want to add it to the **functions** not just the libraries; What do you mean by "change each function name"? what good does it make if the compiled function are without the suffix?? – Benny K Sep 03 '19 at 08:34
  • ? Example: There is `fftw_plan_awake` and `fftwf_plan_awake` and `fftwl_plan_awake` functions in respectively `libfftw3.so`, `libfftw3f.so` and `libfftw3l.so` libraries. Why would you add a suffix "MyStuff"? Like you want to compile the library for some custom hardware floating point data type implementation? `What do you mean by "change each function name"?` - well, you stated you wanted to add a suffix to functions. So edit the function name and replace the function declaration `fftw_malloc` and all references to this function in the source to `fftwMyStuff_malloc`. The suffix will be added. – KamilCuk Sep 03 '19 at 08:37
  • `what good does it make if the compiled function are without the suffix?` - I have literally no idea, what good does it make to compile with any suffix. Why would you want to rename all functions in a library? What is the point of renaming the functions? That's why I ask, what is the goal you want to achieve with it? Why do you want to do that? I see no reason to add any suffix to functions. – KamilCuk Sep 03 '19 at 08:42
  • Because I want to use 2 separate *.so files in the same application with the same functionality so I want that the functions names inside the library will be also different to prevent 2 threads calling the same function in the **same** so file. – Benny K Sep 03 '19 at 08:42
  • 1
    And that is a completely valid reason and there is a good solution to it. Is just [prefixing](https://stackoverflow.com/questions/10157680/how-can-i-get-gcc-to-add-a-prefix-to-all-symbol-names) not enough? – KamilCuk Sep 03 '19 at 08:45
  • Thank you, will check that but I am not sure it will suffice... do I have to change my code due to symbols renaming? if so it is what I am looking for, if not, what causes the process to call the "correct" function? – Benny K Sep 03 '19 at 08:51
  • 1
    At first I thought you just want to rename the function, that's why I said to rename it in the source. You could add the reason to your question. `objcopy` will not work with shared libraries, so you need to get before linking and execute `objcopy --redefine-syms` or `--prefix-symbols` on object files before linking. And then link. – KamilCuk Sep 03 '19 at 08:53
  • is it possible to add `--prefix-symbols` as some kind of parameter to the `./configure` file? the compilation and linking are automatic after hitting `make` – Benny K Sep 03 '19 at 08:59
  • 1
    Please read [XY problem](https://meta.stackexchange.com/questions/66377/what-is-the-xy-problem). If you want to link two versions of a library in one application, ask how to do that, don't ask about how to do something else that you think would solve your problem. The proper solution is to link your library statically. – Cris Luengo Sep 03 '19 at 16:27
  • @CrisLuengo - would static linking cause that my *.so file will always invoke the "correct" functions? – Benny K Sep 03 '19 at 17:39
  • I don't know what your situation is exactly. But say you have program P that links to fftw.so. You want to build a module m.so for program P, that also uses fftw.so, but you want to use a different version. Instead, built m.so to link to static library fftw.a. Make sure your m.so doesn't export the FFTW functions. Now P can link to m.so, and still use fftw.so, and m.so will be using the functions from fftw.a, which was a different version than what is in fftw.so being linked. This is really simple, and requires no weird tricks. – Cris Luengo Sep 03 '19 at 19:53
  • @CrisLuengo I hope that my situation is much simpler: I have an application which links to `libreg.so` (which links to `fftw.so`) and `libtrk.so` (which links to `fftwtrk.so` ) I want to make sure that both so files calls the functions in the corresponding fftw so files. Would static linking will ensure that? – Benny K Sep 03 '19 at 21:19
  • If you build one of these .so files yourself, build that one with a static fftw. If you build both with a static fftw it's even easier, because then you don't need to worry about these .so files exporting symbols from fftw. But if you're building both these .so files yourself, why not link them against the same fftw? – Cris Luengo Sep 03 '19 at 21:32
  • Thanks, I am building all of them myself. I can't link to the same library since fftw is not considered thread safe and I am calling each so file from a different thread – Benny K Sep 03 '19 at 21:34
  • http://www.fftw.org/fftw3_doc/Thread-safety.html -- They're saying that it is beneficial to share plans across threads. You just need to be careful to plan in only one thread, or to put a lock around the planning. The execution can be done from multiple threads even sharing the same plans. – Cris Luengo Sep 03 '19 at 21:38
  • Yes I have read that, this is why I decided to use two different so files with the same functionality in the first place..... you actually need some kind of mutex for all the functions except fftw_execute so it slows down run times. – Benny K Sep 03 '19 at 21:44

0 Answers0