Re: Gimp 1.3 compile and link dependencies
At 04:13 05.02.01 +, Nick Lamb wrote: On Mon, Feb 05, 2001 at 02:26:23AM +0100, Hans Breuer wrote: The windoze version of gimpwidgefts can't include two symbols for different implementation of the same function. There is only one version of the dll in memory, even if loaded by another process. The code is shared across process boundaries while the data is not. Try making two copies of the DLLs with different filenames, and link plug-ins to one while gimp.exe links the other, that should fix it right? Yepp, but I was serching for a better way. Most of the stuff in gimpwidgets appears to be useful for other apps as well, but the whole lib won't be reusable, if there is a Gimp dependency. (I especially like the simplified method to construct option menus.) Maybe the widgets, which are using Gimp internals should be split from gimpwidgets and linked into gimpui.dll (for plug-ins) or gimp.exe ? Hans Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert
Re: Gimp 1.3 compile and link dependencies
At 16:02 05.02.01 +0100, Michael Natterer wrote: Hans Breuer [EMAIL PROTECTED] writes: On Mon, Feb 05, 2001 at 02:26:23AM +0100, Hans Breuer wrote: The windoze version of gimpwidgefts can't include two symbols for different implementation of the same function. There is only one version of the dll in memory, even if loaded by another process. The code is shared across process boundaries while the data is not. Coming back to your real problem: before we started to restructure the libgimp stuff, those widgets were linked statically into the GIMP, so it's probably the best idea to continue to do so for Win32. Maybe you can do some Makefile voodoo and send a patch ? Maybe it could be done by makefile tweaking, but it seems to be more simple to *really* dynamically link the 11 missing function at runtime; and actually it was :-) I've learned today, that this is a common feature of the ELF binaries, but on win32 the exporting library needs to be known at link time; or needs some additional coding ... Gimp 1.3 and it's plug-ins are now running again under win32! ... could send a patch, but I even could directly commit to cvs, if my previous patch get's absolution ... I'm assuming the list isn't really interested, how Micro$oft makefiles do look like ... Have Fun, Hans Hans "at" Breuer "dot" Org --- Tell me what you need, and I'll tell you how to get along without it.-- Dilbert
Re: Gimp 1.3 compile and link dependencies
Hi, Hans Breuer [EMAIL PROTECTED] writes: while adapting make and export definition files for the win32 build of Gimp 1.3, there where some questions ariseing : - what are the supposed dependency between all the libgimp* libraries ? you got it right in your graphics below. what I have at the moment is (gimp.exe works, but most plug-ins do not yet) : gimp.exe plug-ins + gimpcolor.dll+ gimp.dll + gimpwidgets.dll + gimpui.dll + gimpcolor.dll | + gimpwidgets + gimpmath.dll |+ gimpcolor.dll |+ gimpmath.dll + gimpcolor.dll + gimpmath.dll + gimpwidgets.dll all the above resolves fine except libgimwidgets dependcies, because there are the functions listed below, which need (and have) different implementations in Gimps and Plug-Ins context. Currently I'm linking gimpwidgets.dll against the functions exported by Gimp, but this probably is the reason why most plug-ins aren't running ... I could hack up a windoze specific version for those functions, to dynamically detect, if they are running in Gimp's or Plug-In's context, but does anyone now of a proper cross platform sollution ? critical functions: gimp_palette_get_background gimp_palette_get_foreground gimp_standard_help_func gimp_unit_get_abbreviation gimp_unit_get_digits gimp_unit_get_factor gimp_unit_get_number_of_built_in_units gimp_unit_get_number_of_units gimp_unit_get_plural gimp_unit_get_singular gimp_unit_get_symbol We probably need to export the symbols you listed so you can link gimp against libgimpwidgets. libgimp exports the same symbols but has an implementation that works through the PDB. Second question: - to make Gimp compile again I needed to include some headers in other headers again (see attached patch). Yes, I've read the docs, which say not to do so, but is it really wanted to get a header order dependency ? Please send the patch included in your email, not as zip archive. Makes it easier to read and allows me to comment on the diff in a reply. I have looked into it and parts of it look good, others need a different solution imho. Salut, Sven
Re: Gimp 1.3 compile and link dependencies
At 01:31 05.02.01 +0100, Sven Neumann wrote:
Hans Breuer [EMAIL PROTECTED] writes:
...
all the above resolves fine except libgimwidgets dependcies,
because there are the functions listed below, which need
(and have) different implementations in Gimps and Plug-Ins
context. Currently I'm linking gimpwidgets.dll against
the functions exported by Gimp, but this probably is the
reason why most plug-ins aren't running ...
I could hack up a windoze specific version for those functions,
to dynamically detect, if they are running in Gimp's or Plug-In's
context, but does anyone now of a proper cross platform sollution ?
critical functions:
gimp_palette_get_background
gimp_palette_get_foreground
gimp_standard_help_func
gimp_unit_get_abbreviation
gimp_unit_get_digits
gimp_unit_get_factor
gimp_unit_get_number_of_built_in_units
gimp_unit_get_number_of_units
gimp_unit_get_plural
gimp_unit_get_singular
gimp_unit_get_symbol
We probably need to export the symbols you listed so you can link
gimp against libgimpwidgets. libgimp exports the same symbols but
has an implementation that works through the PDB.
What kind of export do you suggest ? The win32 specific one is already
done by me, but AFAIK the problems is somewhere else.
The windoze version of gimpwidgefts can't include two symbols for
different implementation of the same function. There is only one
version of the dll in memory, even if loaded by another process.
The code is shared across process boundaries while the data is
not.
It might be possible to build a sollution which detects at runtime,
if the dll is loaded by gimp.exe and than dynamically resolve to symbols
exported by gimp.exe. Otherwise the implementation querying the PDB
would be used (this is what I tried to explain above). Obviously the
PDB version does *not* work in the Gim process ...
Second question:
- to make Gimp compile again I needed to include some headers
in other headers again (see attached patch). Yes, I've read the
docs, which say not to do so, but is it really wanted to get
a header order dependency ?
Please send the patch included in your email, not as zip archive.
Makes it easier to read and allows me to comment on the diff in
a reply. I have looked into it and parts of it look good, others
need a different solution imho.
Here it comes. Missing a ChangeLog entry, which I I would write before
really commiting. Something like:
* app/app_procs.c : to get the definiton of G_OS_WIN32 make sure
glib.h get's included first (there must be a better sollution
to do this ...)
* ...
diff --exclude-from=c:\util\tool\diff.ign -u -r
from-cvs/gimp/app/app_procs.c my-gtk/gimp/app/app_procs.c
---
from-cvs/gimp/app/app_procs.c Sun Feb 04 14:25:58 2001
+++
my-gtk/gimp/app/app_procs.c Sun Feb 04 19:05:38 2001
@@ -33,12 +33,12 @@
#include unistd.h
#endif
+#include gtk/gtk.h
+
#ifdef G_OS_WIN32
#include process.h/* For _getpid() */
#endif
-#include
gtk/gtk.h
-
#include "libgimpwidgets/gimpwidgets.h"
#include
"apptypes.h"
diff --exclude-from=c:\util\tool\diff.ign -u -r
from-cvs/gimp/app/appenv.h my-gtk/gimp/app/appenv.h
---
from-cvs/gimp/app/appenv.h Sun Feb 04 14:26:00 2001
+++
my-gtk/gimp/app/appenv.hSun Feb 04 17:51:08 2001
@@ -19,6 +19,7 @@
#ifndef __APPENV_H__
#define __APPENV_H__
+#include glib.h /* gboolean
*/
typedef enum
{
diff --exclude-from=c:\util\tool\diff.ign -u -r
from-cvs/gimp/app/cursorutil.h my-gtk/gimp/app/cursorutil.h
---
from-cvs/gimp/app/cursorutil.h Thu Jan 11 23:33:48 2001
+++
my-gtk/gimp/app/cursorutil.hSun Feb 04 17:32:38 2001
@@ -19,6 +19,9 @@
#ifndef __CURSORUTIL_H__
#define __CURSORUTIL_H__
+#include
gdk/gdktypes.h
+#include gdk/gdkcursor.h
+#include gtk/gtkwidget.h
typedef struct
{
diff --exclude-from=c:\util\tool\diff.ign -u -r
from-cvs/gimp/app/datafiles.h my-gtk/gimp/app/datafiles.h
---
from-cvs/gimp/app/datafiles.h Sun Feb 04 14:26:40 2001
+++
my-gtk/gimp/app/datafiles.h Sun Feb 04 18:42:08 2001
@@ -22,6 +22,7 @@
#ifndef __DATAFILES_H__
#define __DATAFILES_H__
+#include time.h
typedef enum
{
diff --exclude-from=c:\util\tool\diff.ign -u -r
from-cvs/gimp/app/dialog_handler.h my-gtk/gimp/app/dialog_handler.h
---
from-cvs/gimp/app/dialog_handler.h Sun Feb 04 18:50:02 2001
+++
my-gtk/gimp/app/dialog_handler.hSun Feb 04 19:16:42 2001
@@ -20,8 +20,10
@@
#ifndef __DIALOG_HANDLER_H__
#define __DIALOG_HANDLER_H__
-
+#include gmodule.h
+G_MODULE_EXPORT
void dialog_register
(GtkWidget *dialog);
+G_MODULE_EXPORT
void dialog_unregister
(GtkWidget *dialog);
void dialog_register_toolbox (GtkWidget
*dialog);
diff --exclude-from=c:\util\tool\diff.ign -u -r
from-cvs/gimp/app/draw_core.h my-gtk/gimp/app/draw_core.h
---
from-cvs/gimp/app/draw_core.h Thu Jan 11 23:34:00 2001
+++
my-gtk/gimp/app/draw_core.h Sun Feb 04 17:30:02 2001
@@ -19,6 +19,8 @@
#ifndef __DRAW_CORE_H__
#define
Re: Gimp 1.3 compile and link dependencies
On Mon, Feb 05, 2001 at 02:26:23AM +0100, Hans Breuer wrote: The windoze version of gimpwidgefts can't include two symbols for different implementation of the same function. There is only one version of the dll in memory, even if loaded by another process. The code is shared across process boundaries while the data is not. Try making two copies of the DLLs with different filenames, and link plug-ins to one while gimp.exe links the other, that should fix it right? Nick.
