How to build a library on top of GfxLib?

jdebord · Post by **jdebord** » May 27, 2005 17:36

I have a module for plotting curves (plot.bas) and a demo program (plotfunc.bas). The module uses only calls to GfxLib.

If I compile with "fbc plotfunc.bas plot.bas" I obtain the executable (plotfunc.exe) and it runs very well.

If I try to convert the module to a library with "fbc plot.bas -lib" I obtain the library file (libplot.a) without any error.

But when I try to link this library with my demo program with "fbc plotfunc.bas -l plot" I get a whole list of "undefined reference to fb_Gfx..." in libplot.a

Adding #inclib "fbgfx" in plot.bas or plotfunc.bas does not help.

What can I do?

Post by **v1ctor** » May 27, 2005 20:20

The gfx library is only included when GFX statements or functions are used, to make the linking faster. It depends on user32, gdi32, winmm so the command-line would have to include all them, - plus the fbgfx lib itself - or you can add them to an include file using the #inclib directive.

lillo · Post by **lillo** » May 28, 2005 10:23

Just changed inc/fbgfx.bi so it also automatically link in needed libraries. This way just including it in your sources will cause them to be linked, avoiding the problems you encountered... Change in CVS.

jdebord · Post by **jdebord** » May 28, 2005 11:42

Thank you very much for your explanations. I have made the modifications suggested by Victor. Now it works!

I will try to get the new file, but I have never used CVS.

In the meantime, could you please tell me how I can do the same with Linux? Which libraries should be linked?

lillo · Post by **lillo** » May 28, 2005 11:50

Add this to your local copy of inc/fbgfx.bi:

Code: Select all

#inclib "fbgfx"
#ifdef __FB_WIN32__
	#inclib "user32"
	#inclib "gdi32"
	#inclib "winmm"
#elseif defined(__FB_LINUX__)
	#libpath "/usr/X11R6/lib"
	#inclib "X11"
	#inclib "Xext"
	#inclib "Xpm"
	#inclib "Xrandr"
	#inclib "Xrender"
	#inclib "pthread"
#endif

#include it and you're done, from both Win32 and Linux.

jdebord · Post by **jdebord** » May 28, 2005 12:34

OK. Thanks again !

Antoni · Post by **Antoni** » May 28, 2005 14:14

Lillo:

As the problem will happen with any lib extending gfxlib, perhaps the patch you propose should be included in the next release of the headers.

I'm doing a jpeg extension for gfxlib. Any suggestion? I know you too catched the jpeg bug back in 2000...

lillo · Post by **lillo** » May 28, 2005 14:21

Antoni: the change is already in CVS :)

About JPG, I'd suggest you have a look at my JPGalleg codec; it supports almost any JPG you throw at it, including progressive ones. From my experience, if you code a JPG loader, progressive support is a must.
Anyway, I may decide to port JPGalleg to FB one day...

Antoni · Post by **Antoni** » May 28, 2005 14:35

I have the source of JpgAlleg, i will look at it for lib organisation progressive support.
I'm patching the old code I started in QB back in 1999 (i I started then optimizing Dmitry Brant's viewer), but it requires a lot of adaptation to FB features to be useful.

According to the profiler it spends a 75% of its time doing Huffman decoding, bit manipulation is slow...and it spends in IDCT (LLM fixed point) only an 1% of the time, so perhaps I will revert it to floating point for more accuracy..

I'm at 2 seconds to load a 10Mpixel image in a P4 1,4. Don't believe I can go below this...

DrV · Post by **DrV** » May 29, 2005 3:01

I've got the JPGalleg header ported to FB on my local machine but haven't written any examples for it yet (it's untested); I'll commit it to CVS in the off chance that someone will be willing to port the examples. :)