STR #118: typo in src/Makefile (IMGLIBS for IMAGELIBS)

STR #118

Application:	FLTK Library
Status:	1 - Closed w/Resolution
Priority:	2 - Low, e.g. a documentation error or undocumented side-effect
Scope:	3 - Applies to all machines and operating systems
Subsystem:	Config Files
Summary:	typo in src/Makefile (IMGLIBS for IMAGELIBS)
Version:	1.1.4rc2
Created By:	amu.alum.mit
Assigned To:	mike
Fix Version:	1.1.4
Update Notification:	Receive EMails Don't Receive EMails

Trouble Report Files:

No files

Trouble Report Comments:

#1	amu.alum.mit 08:37 Jul 30, 2003

src/Makefile tries to link the .so and .sl versions of libfltk_images against $(IMGLIBS), which is undefined; please change it to $(IMAGELIBS), which actually exists. While you're at it, could you please pull in other library dependencies everywhere rather than just for OS X? The linker might not require it, but it's still good practice. Thanks, and keep up the good work. (RC2 otherwise looks quite promising.)

#2	mike 05:46 Aug 02, 2003

Fixed in CVS for 1.1.4; as for the remaining libraries, they aren't required on other OS's and you still have to link against libfltk anyways on all platforms; it is just the OSX linker that needs the symbol resolution when building the images library...

#3	amu.alum.mit 18:47 Aug 23, 2003

First of all, thanks for fixing the typo. As for dependencies, while I agree that applications should continue to link libfltk in addition to libfltk_*, I also maintain that shared libraries should generally avoid outstanding dependencies even on operating systems that permit them: * If such a library gains a dependency but otherwise retains binary compatibility, applications that use it won't need relinking. * Likewise, all such libraries are dlopen()able. * Some linkers that allow unresolved symbols still warn about them. Granted, none of these points applies too strongly here (though there's certainly something to be said for heeding warnings!), but I'd argue that satisfying dependencies is still good practice. The only catch is that on some platforms (including FreeBSD, I think), you have to be sure to compile an appropriate rpath into the libraries as well as into the ultimate executables. See also http://www.debian.org/doc/debian-policy/ch-files.html#s-libraries . (Apologies for taking so long to reply to this report; my schedule was pretty busy for the past few weeks.)

#4	mike 05:30 Aug 24, 2003

Unfortunately, some operating systems have the reverse problem - linking a shared library to all dependent libraries can sometimes cause other linking errors when you link an app against both the library and its dependents. We've run into this problem on AIX, so it is possible we might be able to isolate this just to DSO generation.