Nicola Pero wrote:
>
> Perhaps a problem might be with static libraries ... If a library is
> static, you don't want the __declspec(dllimport) to happen. Manually
> filtering all libraries is horrible but you are sure that, if you are
> linking against many libraries and some are shared some are
> > Can I ask one question then - is 'BUILD_libgnustep_gui_DLL' and
> > 'libgnustep_gui_DLL' a general standard for building unix stuff on
> > Windows, or is it more or less a gnustep-only trick ?
> >
> > Because if it's a gnustep-only trick, we could modify it in the following
> > way:
> >
>
Nicola Pero wrote
> Can I ask one question then - is 'BUILD_libgnustep_gui_DLL' and
> 'libgnustep_gui_DLL' a general standard for building unix stuff on
> Windows, or is it more or less a gnustep-only trick ?
>
> Because if it's a gnustep-only trick, we could modify it in the following
> way:
>
> 2. As the new backend works with subproject these must now be able to
> correctly set set the XXX_ISDLL flags as well. Currently we have this
> correct for applications, libraries and bundles, but not for
> subprojects. Before adding a new workaround I would prefer a general
> solution that
Fred Kiefer wrote:
> 1. the new backend results in the line
> GRAPHIC_LIBS=-ltiff -lX11
> being written to the files config.make and back.make even when not
> configured for any X backend.
>
Fixed this.
--
Adam Fedor, Digital Optics Corp. | I'm glad I hate spinach, because
http://www.d
1. the new backend results in the line
GRAPHIC_LIBS=-ltiff -lX11
being written to the files config.make and back.make even when not
configured for any X backend.
2. As the new backend works with subproject these must now be able to
correctly set set the XXX_ISDLL flags as well. Currently we ha
