| | [ Return to Bugs & Features | SVN ⇄ GIT ]
STR #1959
| Application: | FLTK Library |
|---|
| Status: | 2 - Closed w/o Resolution |
|---|
| Priority: | 1 - Request for Enhancement, e.g. asking for a feature |
|---|
| Scope: | 2 - Specific to an operating system |
|---|
| Subsystem: | Build Files |
|---|
| Summary: | Building of image DLL's on win32 |
|---|
| Version: | 1.4-feature |
|---|
| Created By: | ianmacarthur |
|---|
| Assigned To: | ianmacarthur |
|---|
| Fix Version: | Unassigned |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
No files
Trouble Report Comments:
| |
| #1 | ianmacarthur
03:36 May 09, 2008 |
| Note: I assume this issue is specific to winXX hosts, but I suppose it might apply to some other hosts.
The issue: On this win32/mingw host, if I build fltk with --enable-shared, and with --enable-local-[jpeg|png|zlib] then DLL's are cretaed for the "main" fltk libs, e.g. fltk, fltk-image, fltk-gl etc, but *not* for the local image libs (png, jpeg, zlinb.)
I think that if we have --enable-shared, we maybe ought to build shared versions of the image libs too - the static versions may not be what's needed by a fltk DLL at runtime.
I don't know to what extent other hosts might have issues with this, but I'm pretty sure it is an issue for win32 at least. | |
| |
| #2 | ianmacarthur
05:08 Oct 19, 2008 |
| I did a few tests, and it does seem that using a static PNG lib with a fltk DLL is indeed problematic in some circumstances - so maybe we do need to make DLL versions of PNG Zlib and JPEG if we do a "shared" build? | |
| |
| #3 | ianmacarthur
02:46 Sep 05, 2014 |
| Closing this - the build environ has moved on... | |
[ Return to Bugs & Features ]
|
| |
