I have connected FFTW library (http://www.fftw.org/)to a custom mentalray DLL that I have created in C++(A DLL file I have compiled on Linux (CENTOS) Using netbeans. I put this DLL in the software (Autodesk Maya) in a folder for adding custom plugins. The problem is I have installed FFTW on the computer and I dont know how to link Maya to the FFTW library. On windows I would put the FFTW dll in the folder that contains the maya.exe file that is the application Launch exe file.
Basically my question to a normal LINUX programer is if I install the FFTW libraries on linux and create a .dll for a software that links to it how do I get the software to link to the FFTW libraries?
let me know if you need me to provide anymore info..
You don't need to do anything special - so long as the FFTW libraries are at the expected location (/usr/local/lib) then you can just link to then as normal (gcc ... -lfftw3 ...).
Make sure to compile the right version: fftw floats (i.e., fftwf) versus fftw doubles. You should have a libfftw3f.3.so file, for example.
If you are using dlopen to call functions in fftw, place the .so file you generated somewhere in your $PATH.
If the mental ray "DLL" is a static library, you should configure fftw with --enable-static --disable-shared and run sudo make install.
If the mental ray "DLL" is a dynamic library, you should configure fftw with --disable-static --enable-shared and run sudo make install.
To be safe, you can do both.
sudo make install will place the fftw "DLLs" in the right place, as long as your mental ray "DLL" is using fftw conventionally (i.e., importing a fftw.h file).
Check for linker errors when you try to build your "DLL." If you see linker errors, you neglected to run sudo make install and your DLL won't work at all regardless of what you do with fftw.
Related
I am trying to build jpeg-9d library from sources on Alpine Linux (3.14.2).
I would like to obtain only static libraries (.a files) from libjpeg.
This is because I would like to get all 3rd party dependencies all-in-one into my application. And this is because I chose Alpine Linux due static musl C library.
The compilation actually was fine, all configure step, make, make install went fine.
./configure --disable-shared
make
make install
But after this I see libjpeg.so file in /usr/local/lib directory.
Actually both libjpeg.a and libjpeg.so are present in /usr/local/lib.
install.txt says that using --disable-shared should be enough.
But it does not work.
I built many 3rd party libraries into static configuration on Alpine Linux;
all of them produced .a files only (of course, I used additional configuration flags),
like zlib, bzip2, xz, zstd, libpng, giflib (small patch was required), expat, freetype2, fontconfig, json, openssl, tiff, boost, etc.
Previously I used libjpeg-6b, and instead of using just make install I used
make install-lib
command and I got only .a files. Old jpeg-6b supported install-lib target. But the new libjpeg-9d does not support this target in make files.
I think it is a bug in jpeg-9d configuration scripts.
Any chance to work-around it or even fix?
Actually --enable-shared=no works fine, no .so files are copied into /usr/local/lib!
So, I can use --enable-shared=no instead of --disable-shared.
./configure --enable-shared=no
make
make install
Maybe it is an issue of automake/autoconf Alpine Linux utilities.
I'm trying to generate the lib files for freeglut library. I've installed cygwin and according to README file that comes with the library,
Building and Installing the Libraries with Cygwin
=================================================
To build "freeglut" under Cygwin, you have two choices:
- You can build a normal Cygwin library, which depends on Cygwin's X11
libraries. To do this, you can just use the normal autotools incantation:
./configure && make install
- Alternatively, you can build a DLL which does not depend on X11 and links
against the opengl32 DLL. To do this, configure need a few more flags:
./configure CPPFLAGS=-mno-cygwin LDFLAGS=-mno-cygwin --without-x && make install
If you don't have MSVC, Open Watcom or Cygwin
=============================================
But If I run ./configure, I got this error
$ ./configure CPPFLAGS=-mno-cygwin LDFLAGS=-mno-cygwin --without-x && make install
-bash: ./configure: No such file or directory
Is there something I need to install in order to solve this issue? The contents of the folder doesn't have configure. These are the files in the folder
If you need freeglut, you need to install the cygwin package libglut-devel
Looking inside setup.ini you will find its description:
libglut-devel
sdesc: "OpenGL Utility Toolkit library"
ldesc: "freeglut
is a completely OpenSourced alternative to the OpenGL Utility Toolkit
(GLUT) library. GLUT was originally written by Mark Kilgard to support
the sample programs in the second edition OpenGL 'RedBook'. Since
then, GLUT has been used in a wide variety of practical applications
because it is simple, widely available and highly portable. GLUT (and
hence freeglut) allows the user to create and manage windows
containing OpenGL contexts on a wide range of platforms and also read
the mouse, keyboard and joystick functions."
category: X11
I'm trying to build a portable version of gcc 4.8.2. (for only C/C++ languages) The end result is have gcc installed into a specific application directory, eg, /opt/gcc-4.8.2 so that I can copy that directory from one computer to another (all computers are either intel corei5 or corei7, running recent Linux versions, eg, Ubuntu 12, Suse 10/11, Centos 5 & 6).
So far I'm able to build gcc ok, using --prefix to have the gcc outputs placed in a single directory (which can then be later copied to the other hosts). I configured & built gcc's dependencies (gmp, mpfr, mpc, isl) to have --disable-shared, so I can be sure that the final gcc, when copied to other hosts, won't complain about missing libraries or symbols.
I have a question with cloog. I configured gcc with --with-cloog (to pick up my locally built cloog, which I built along with the other gcc dependencies). However, what I don't know, is whether I also need to copy the cloog libraries and binary to each host I copy gcc to?
Also, how can I test gcc & cloog interaction? Is there a simple C file example and/or gcc command line that can be used to test whether gcc is successfully making use of cloog?
Additionally, are there any other considerations when trying to build a gcc which I then want to run on other hosts?
It depends if cloog is installed as a shared library libcloog-isl.so.* or as a static one libcloog.a ; use
ldd $(gcc-4.8 -print-file-name=cc1)
to find out. Of course you need to install all the shared libraries dependencies. If libcloog*so appears in the output of above ldd command, it is a shared library. Otherwise a static one.
You could set the LD_LIBRARY_PATH, or add the directory containing libcloog-isl.so.* (e.g. /usr/local/lib/ or /opt/lib/ etc...) to /etc/ld.so.conf (then run ldconfig)
I am not entirely sure your gcc build can run on every platform you mentioned. There might be libc* dependencies. See this. And perhaps also binutils dependencies (notably for gcc-4.8 -flto compilations).
To test gcc just compile with optimizations (e.g. gcc-4.8 -Wall -O3) some non-trivial file.
I am using Ubuntu 13.04 and installed mingw-w64 using apt-get install mingw-w64. I can compile and link a working 64-bit version of my program with the following command:
x86_64-w64-mingw32-g++ code.cpp -o app.exe
Which generates a 64-bit app.exe file.
What binary or command line flags do I use to generate a 32-bit version of app.exe?
That depends on which variant of toolchain you're currently using. Both DWARF and SEH variants (which come starting from GCC 4.8.0) are only single-target. You can see it yourself by inspecting the directory structure of their distributions, i.e. they contain only the libraries with either 64- or 32-bit addressing, but not both. On the other hand, plain old SJLJ distributions are indeed dual-target, and in order to build 32-bit target, just supply -m32 flag. If that doesn't work, then just build with i686-w64-mingw32-g++.
BONUS
By the way, the three corresponding dynamic-link libraries (DLLs) implementing each GCC exception model are
libgcc_s_dw2-1.dll (DWARF);
libgcc_s_seh-1.dll (SEH);
libgcc_s_sjlj-1.dll (SJLJ).
Hence, to find out what exception model does your current MinGW-w64 distribution exactly provide, you can either
inspect directory and file structure of MinGW-w64 installation in hope to locate one of those DLLs (typically in bin); or
build some real or test C++ code involving exception handling to force linkage with one of those DLLs and then see on which one of those DLLs does the built target depend (for example, can be seen with Dependency Walker on Windows); or
take brute force approach and compile some test code to assembly (instead of machine code) and look for presence of references like ___gxx_personality_v* (DWARF), ___gxx_personality_seh* (SEH), ___gxx_personality_sj* (SJLJ); see Obtaining current GCC exception model.
I am using autoconf gnu tools to build my product.
It generates both the shared as well as static library for any library where *.la is mentioned.
The issue is if you use .la to link your binary in Makefile.am.
It links with the dynamic library but when you use ldd to the binary, it says
"not a dynamic executable" although it links with shared library. I proved it by removing the shared library after the binary is built and then tried to run the binary. It didn't find the shared library and couldn't run.
Another question is how to put library in a specified location using Makefile.am direction ?
Looks like you run ldd on the wrapper scripts created by libtool. They are used to link uninstalled libraries with uninstalled executables. Real binaries are placed in .libs directory.
You can install a lib to some specific place in this way
mylibrary_LTLIBRARIES = libmylibrary.la
mylibrarydir = ${libdir}/my_plugins/