PDA

View Full Version : fftw3-3f dll problem with linking


vcmohan
18th January 2008, 10:50
This may not be the forum to pose this question, but I hope some kind hearted helpful person will answer here.

I have earlier used fftw3 dll (release 2) and my plugins fftquiver and fqsharp both are linked using their lib file. I am now trying to upgrade to using the latest release 3.1.2

The instructions in the readme file of fftw dll are as follows:

In order to link to these .dll files from Visual C++, you need to
create .lib "import libraries" for them, and can do so with the "lib"
command that comes with VC++. In particular, run:
lib /machine:i386 /def:libfftw3-3.def
lib /machine:i386 /def:libfftw3f-3.def
lib /machine:i386 /def:libfftw3l-3.def

The single- and double-precision libraries use SSE and SSE2, respectively,
but should also work on older processors (the library checks at runtime
to see whether SSE/SSE2 is supported and disables the relevant code if not).

They were compiled by the GNU C compiler for MinGW, specifically:
i586-mingw32msvc-gcc (GCC) 3.4.5 (mingw special)

I have inserted these commands in the prelink step. Inspite of it I get an error stating that the ___imp___fftw3f__ calls were unresolved. The plg file of VC++ reads as

--------------------Configuration: FQ2Sharp - Win32 Release--------------------

Command Lines
Creating temporary file "C:\DOCUME~1\VC4536~1.MOH\LOCALS~1\Temp\RSPF.bat" with contents
[
@echo off
lib /machine:i386 /def:libfftw3f-3.def
]
Creating command line "C:\DOCUME~1\VC4536~1.MOH\LOCALS~1\Temp\RSPF.bat"
Creating temporary file "C:\DOCUME~1\VC4536~1.MOH\LOCALS~1\Temp\RSP10.tmp" with contents
[
kernel32.lib user32.lib gdi32.lib winspool.lib comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib uuid.lib odbc32.lib odbccp32.lib /nologo /dll /incremental:no /pdb:"Release/FQ2Sharp.pdb" /machine:I386 /out:"Release/FQ2Sharp.dll" /implib:"Release/FQ2Sharp.lib"
.\Release\FQ2Sharp.obj
]
Creating command line "link.exe @C:\DOCUME~1\VC4536~1.MOH\LOCALS~1\Temp\RSP10.tmp"
fftw3 dll import
Microsoft (R) Library Manager Version 6.00.8168
Copyright (C) Microsoft Corp 1992-1998. All rights reserved.

Creating library libfftw3f-3.lib and object libfftw3f-3.exp
Output Window
Linking...
Creating library Release/FQ2Sharp.lib and object Release/FQ2Sharp.exp
FQ2Sharp.obj : error LNK2001: unresolved external symbol __imp__fftwf_destroy_plan
FQ2Sharp.obj : error LNK2001: unresolved external symbol __imp__fftwf_free
FQ2Sharp.obj : error LNK2001: unresolved external symbol __imp__fftwf_execute
FQ2Sharp.obj : error LNK2001: unresolved external symbol __imp__fftwf_plan_dft_c2r_2d
FQ2Sharp.obj : error LNK2001: unresolved external symbol __imp__fftwf_plan_dft_r2c_2d
FQ2Sharp.obj : error LNK2001: unresolved external symbol __imp__fftwf_malloc
FQ2Sharp.obj : error LNK2001: unresolved external symbol __imp__fftwf_plan_dft_2d
Release/FQ2Sharp.dll : fatal error LNK1120: 7 unresolved externals
Error executing link.exe.



Results
FQ2Sharp.dll - 8 error(s), 0 warning(s)


Incase of usage of Avisynth dll, this extra step of creation of lib is not required. Why this fftw dll linkage requires it? Where I am going wrong?

Fizick does a late binding but I do not see him creating the lib.

IanB
19th January 2008, 07:58
And did you include the libfftw3f-3.lib in your link command?

Fizick
19th January 2008, 09:42
I prefer use a (undocumented hack) dynamic loading instead of static :)

vcmohan
19th January 2008, 10:35
And did you include the libfftw3f-3.lib in your link command?

The fftw3f-3.lib is in the same directory as FQSharp which I am compiling. So automatically the lib file is included, I assume. I have tried adding this FQSharp directory to the lib directories to be looked into by compiler. The error still persists.

Specifying this file in project/settings/link-> general linked correctly. Thanks.

Fizick@ The dynamic loading which is used appers to be similar to what I read as late binding. Whether it is late or early binding the relative offsets of the symbols must be known at that time. This step of creating lib file may be for getting those offsets.

However I am a bit (?) confused.

Fizick
19th January 2008, 13:15
with dynamic LoadLibrary we need in function name only.
And we have control on error due to DLL loading.

IanB
19th January 2008, 22:47
Dynamic loading or late binding as you call it, involves using function pointers in your code in place of the actual function declarations.

As you initialize your application you LoadLibrary() the .DLL and then lookup and initialize the values for your function pointers with GetProcAddress() calls.

This method gives you more control. You may implement a smart algorithm to search for the .DLL You may choose to handle different revisions of the .DLL You may give helpfull error messages when the .DLL cannot be found or is not a suitable version.

vcmohan
20th January 2008, 03:46
thanks. will try.

vcmohan
29th January 2008, 04:17
with dynamic LoadLibrary we need in function name only.
And we have control on error due to DLL loading.

I have taken the liberty to use your style of late binding. I am using your header file with slight modifications. Thanks.

Fizick
29th January 2008, 14:15
I see you added suppot arbitrary for libfftw3f-3.dll or FFTw3.dll or fftw.dll in Fftquiver.
So, there are no any incompatibility issues of various versions?
Do you see any speed increasing in new versions?

vcmohan
30th January 2008, 08:32
So, there are no any incompatibility issues of various versions?
Do you see any speed increasing in new versions?

I checked with libfftw3f-3 and fftw3 dlls which I downloaded from the fftw org site. I find both versions work ok. Since the proc addresses are obtained for the same calls / symbols and these are present in the full fftw.h file there should not be any problem. Only if some specific calls not available in older versions are used there will be problem. At those instances I can use a modified check and error reporting.

I have not checked for any hit on speed. Since the offsets (or proc addresses) are obtained in the constructor only once this delay if any occurs. I have seen in some discussions that there will be a hit in time for late binding. Possibly if one repeatedly tries to get the proc addresses, there may be a hit.

I have not checked whether there are any improvements in time between versions.