FreeImage linking problems

External libraries (GTK, GSL, SDL, Allegro, OpenGL, etc) questions.
Post Reply
Manfred
Posts: 14
Joined: Jul 04, 2010 0:20
Contact:

FreeImage linking problems

Post by Manfred »

Hi all,

I need to load BMP, PNG and GIF files of any color depht, and quantize them to simple 1-bit-per-pixel for further processing (PCB manufacture). The FreeImage library seems to be the natural choice for this - but I can't get it to run, and I don't know why.

I'm using FreeBasic 1.08.1, 32 bits, on Windows 10, 64 bits. The FreeImage.bi file is for FreeImage 3170, according to its header, and I placed the 32 bit FreeImage.dll version 3.17.0 file in the FreeBasic/lib/win32 directory. I also placed it in the directory where my source files are, just in case.

If I copy, paste and try to compile the example given on this page

https://www.freebasic.net/wiki/ExtLibfreeimage

all I get when trying to compile is linker error messages:

--------------------------------------------------------------------------------------------------------------------
Compiler output:
C:\PortablePrograms\FreeBasic\bin\win32\ld.exe: C:\pdat\FreeBasic\BMPtoGcode\fitest.o:fake:(.text+0x30): undefined reference to `FreeImage_GetFileType@8'
C:\PortablePrograms\FreeBasic\bin\win32\ld.exe: C:\pdat\FreeBasic\BMPtoGcode\fitest.o:fake:(.text+0x43): undefined reference to `FreeImage_GetFIFFromFilename@4'
C:\PortablePrograms\FreeBasic\bin\win32\ld.exe: C:\pdat\FreeBasic\BMPtoGcode\fitest.o:fake:(.text+0x7c): undefined reference to `FreeImage_Load@12'
C:\PortablePrograms\FreeBasic\bin\win32\ld.exe: C:\pdat\FreeBasic\BMPtoGcode\fitest.o:fake:(.text+0x99): undefined reference to `FreeImage_FlipVertical@4'
C:\PortablePrograms\FreeBasic\bin\win32\ld.exe: C:\pdat\FreeBasic\BMPtoGcode\fitest.o:fake:(.text+0xa1): undefined reference to `FreeImage_ConvertTo32Bits@4'
C:\PortablePrograms\FreeBasic\bin\win32\ld.exe: C:\pdat\FreeBasic\BMPtoGcode\fitest.o:fake:(.text+0xac): undefined reference to `FreeImage_GetWidth@4'
C:\PortablePrograms\FreeBasic\bin\win32\ld.exe: C:\pdat\FreeBasic\BMPtoGcode\fitest.o:fake:(.text+0xb7): undefined reference to `FreeImage_GetHeight@4'
C:\PortablePrograms\FreeBasic\bin\win32\ld.exe: C:\pdat\FreeBasic\BMPtoGcode\fitest.o:fake:(.text+0xeb): undefined reference to `FreeImage_GetBits@4'
C:\PortablePrograms\FreeBasic\bin\win32\ld.exe: C:\pdat\FreeBasic\BMPtoGcode\fitest.o:fake:(.text+0xf6): undefined reference to `FreeImage_GetPitch@4'

Results:
Compilation failed

System:
FBIde: 0.4.6
fbc: FreeBASIC Compiler - Version 1.08.1 (2021-07-05), built for win32 (32bit)
OS: Windows NT 6.2 (build 9200)
----------------------------------------------------------------------------------------------------------

Could anybody please help me to fix this problem? Maybe an older version of FreeImage, but which one, and where do I get the .bi file for it?

Or maybe some other library that will do what I need?

This problem is not new. I saw a short thread from 2015, in which somebody described the same problem, and then reported that he solved it by using a different FreeImage version - but he didn't tell which one.

Any help is very welcome.


Manfred
demosthenesk
Posts: 293
Joined: Jul 15, 2021 7:23
Location: Greece
Contact:

Re: FreeImage linking problems

Post by demosthenesk »

1) checkin .bi file if there are these functions
2) set a -l freeimage option to compiler setting
Manfred
Posts: 14
Joined: Jul 04, 2010 0:20
Contact:

Re: FreeImage linking problems

Post by Manfred »

I checked the .bi file. The functions are declared in it, but are not actually present in that file. If I understand this right, the functions proper will be in the .dll.

I added the -l FreeImage to the command line options in the IDE's FreeBasic settings. No change. I still get the same errors.
demosthenesk
Posts: 293
Joined: Jul 15, 2021 7:23
Location: Greece
Contact:

Re: FreeImage linking problems

Post by demosthenesk »

1) Try to set -l freeimage with lowercase
2) Check that dll are in win32/win64 lib folder according to your architecture 32/64
3) try to set the include and lib path, -i inc_path, -p lib_path
example from gui lib w9
c:/users/demos/bin/freebasic-1.10.1-winlibs-gcc-9.3.0/fbc64.exe -c -m "main" -b "main.bas" -i "C:/Users/demos/Bin/FreeBASIC-1.10.1-winlibs-gcc-9.3.0/inc" -p "C:/Users/demos/Bin/FreeBASIC-1.10.1-winlibs-gcc-9.3.0/lib/win64" -l window9
SARG
Posts: 1888
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FreeImage linking problems

Post by SARG »

After some unsucessfull tries I looked inside the dll to find the function names.
In fact there is an underscore in front of the names (eg _FreeImage_GetFileType) so obviously the functions are not found.
And I don't know why.

Two workarounds in freeimage.bi (for each function you use) :

1/

Code: Select all

declare function _FreeImage_GetFileType(byval filename as const zstring ptr, byval size as long = 0) as FREE_IMAGE_FORMAT
and you need to add an underscore in your code

or just

2/

Code: Select all

 declare function FreeImage_GetFileType alias "_FreeImage_GetFileType" (byval filename as const zstring ptr, byval size as long = 0) as FREE_IMAGE_FORMAT
edit : there is an example for VB6 in the download (dll + other stuff) and functions are declared as way 2.
dodicat
Posts: 8267
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: FreeImage linking problems

Post by dodicat »

If you call a dll at compile time (usual way), the easiest method is to put the dll in the same folder as your source code and include the .bi file which will call by #inclib and immediately find it.
If you call at runtime with dylibload/dylibsymbol then you can use the the path to your dll, (... FreeBasic/lib/win32) you said.
Only after these basic rules can you now investigate function names e.t.c.
SARG
Posts: 1888
Joined: May 27, 2005 7:15
Location: FRANCE

Re: FreeImage linking problems

Post by SARG »

@dodicat
I guess that freeimage.bi need to be changed according the 'new' function names otherwise nothing can't work.
dodicat
Posts: 8267
Joined: Jan 10, 2006 20:30
Location: Scotland

Re: FreeImage linking problems

Post by dodicat »

The .a file:
https://sourceforge.net/projects/fbc/fi ... Libraries/
is no better.
example of a version function from the .a file
__ZN6LibRaw13versionNumberEv
which breaks down to
undefined reference to `LibRaw::versionNumber()@0'
if I use
extern "windows"
declare function getversion alias "_ZN6LibRaw13versionNumberEv"() as long
end extern
(fb 10.1)
maybe some very old fb versions could be tested, the .a lib is old.
Loading these files in windows can be achieved (BMP, PNG and GIF files of any color depth), 32 bit or 8 bit depth.
https://www.freebasic.net/forum/viewtop ... ad#p305098
(last post)
converting to one bit/byte per pixel should be solvable.
Manfred
Posts: 14
Joined: Jul 04, 2010 0:20
Contact:

Re: FreeImage linking problems

Post by Manfred »

OK! The underscores were the problem! SARG hit the nail!

I edited the .bi file, adding those underscores to every function and sub name in the declarations. I then edited the example program to add those underscores, and now it compiles without errors.

Now I can continue writng my program. FreeImage seems to provide all the image manipulation functions I need.

Thanks a lot!

Manfred
paul doe
Posts: 1878
Joined: Jul 25, 2017 17:22
Location: Argentina
Contact:

Re: FreeImage linking problems

Post by paul doe »

The issue happens because the names for 32-bit functions are indeed mangled with an underscore for exported symbols (an archaic convention from Ye Olde Days). I've quickly thrown together a 'fixed' header (it's their snafu, not FB's team) to fix the issue:

https://gist.github.com/glasyalabolas/5 ... fc4cb870a8

Works with no issues for me here (Win10). Please, somebody test it on Linux and report if there's an issue so I can update it if needed.
marcov
Posts: 3503
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: FreeImage linking problems

Post by marcov »

SARG wrote: Oct 30, 2024 8:49 In fact there is an underscore in front of the names (eg _FreeImage_GetFileType) so obviously the functions are not found.
And I don't know why.
Afaik COFF symbols traditionally had an underscore prefix, and ELF ones not. Sometimes the backend tooling takes care of that, sometimes not.
Post Reply