Building against GnuWin32 binaries of libjpeg etc?

Hi all,

I'm new to GraphicsMagick and just trying to get started
with it using
MinGW. I would like to make use of it in a Windows port of
some code
that I already have running on Linux.

I have got the 'developer' versions of libpng, libjpeg,
libtiff, zlib,
libbz2 etc installed on my system. I'm using the GnuWin32
installers for
each of these. These are well-built and easily installed,
but don't seem
to be correctly detected by the GraphicsMagick ./configure
script, nor
do there seem to be ./configure command line options that
would allow
them to be detected correctly.

Is there any way that I can build GraphicsMagick against
these installed
libraries, or must I download and compile each of those
first? Can I put
in a vote for improving support of MinGW, perhaps in the
form of a
simple binary installer suitable for MinGW users?

Note, for example, that another graphics library, GD, is
available for
direct use in very convenient form here:
http:
//gnuwin32.sourceforge.net/packages/gd.htm

Cheers
JP


------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Graphicsmagick-help mailing list
Graphicsmagick-helplists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gra
phicsmagick-help

On Mon, 26 Nov 2007, John Pye wrote:

> I'm new to GraphicsMagick and just trying to get
started with it using
> MinGW. I would like to make use of it in a Windows port
of some code
> that I already have running on Linux.

Great!

> I have got the 'developer' versions of libpng, libjpeg,
libtiff, zlib,
> libbz2 etc installed on my system. I'm using the
GnuWin32 installers for
> each of these. These are well-built and easily
installed, but don't seem
> to be correctly detected by the GraphicsMagick
./configure script, nor
> do there seem to be ./configure command line options
that would allow
> them to be detected correctly.

All of my dealings with MinGW have been via the MSYS shell
and 
utilities.  The GnuWin32 project seems to somehow use bare
Windows 
with GCC since as I recall, its Makefiles use Windows paths
rather 
than Unix style paths.  Regardless, I assume that it should
be 
possible to use libraries built by the GnuWin32 project
since the 
compiler is the same.

Usually I build the add-on libraries from source code using
their 
provided build mechanisms.  I do test with MinGW32
regularly.

For your case, I recommend using the MSYS shell and adding
CPPFLAGS 
and LDFLAGS configure options to find the GnuWin32 libraries
you 
installed.  It is likely that the GnuWin32 library DLLs will
also need 
to be in the MSYS executable search path (PATH environment
variable).

> Is there any way that I can build GraphicsMagick
against these installed
> libraries, or must I download and compile each of those
first? Can I put
> in a vote for improving support of MinGW, perhaps in
the form of a
> simple binary installer suitable for MinGW users?

There is no such thing as a "simple binary
installer" due to the need 
to satisfy the GPL license, and other licenses.

> Note, for example, that another graphics library, GD,
is available for
> direct use in very convenient form here:
> http:
//gnuwin32.sourceforge.net/packages/gd.htm

Yes, this package is built by the same anonymous person
(persons?) who 
builds the other GnuWin32 packages.  It is natural that it
plays well 
with GnuWin32.

Bob
======================================
Bob Friesenhahn
bfriesensimple.dallas.tx.us, http://w
ww.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMag
ick.org/


------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Graphicsmagick-help mailing list
Graphicsmagick-helplists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gra
phicsmagick-help

Hi Bob,

Bob Friesenhahn wrote:
> On Mon, 26 Nov 2007, John Pye wrote:
>> I have got the 'developer' versions of libpng,
libjpeg, libtiff, zlib,
>> libbz2 etc installed on my system. I'm using the
GnuWin32 installers for
>> each of these. These are well-built and easily
installed, but don't seem
>> to be correctly detected by the GraphicsMagick
./configure script, nor
>> do there seem to be ./configure command line
options that would allow
>> them to be detected correctly.
>
> All of my dealings with MinGW have been via the MSYS
shell and 
> utilities.  The GnuWin32 project seems to somehow use
bare Windows 
> with GCC since as I recall, its Makefiles use Windows
paths rather 
> than Unix style paths.  Regardless, I assume that it
should be 
> possible to use libraries built by the GnuWin32 project
since the 
> compiler is the same.

I have had experience linking against GnuWin32 libraries
using MSYS and 
SCons. It all works fine, so I am certain that it is
possible to make 
use of those libraries from GCC on MinGW. Perhaps some
issues with 
unix/windows path syntax, but that is all handled my MSYS
and shouldn't 
affect anything at the level of GCC/G++.

>
>
> Usually I build the add-on libraries from source code
using their 
> provided build mechanisms.  I do test with MinGW32
regularly.

If that is the case, can I suggest that you do a big build
as follows, 
and make a tarball of the result?

mkdir ~/magick_root
./configure --without-perl --prefix=/mingw
make
make install DESTDIR=/home/bob/magick_root/
cd ~/magick_root
tar jcvf graphicsmagic-mingw.tar.bz2 *

This would be sufficient to create a binary that other
developers like 
me could make use of, without the need for me to go through
the job of 
downloading libping, libtiff, etc. I could use the GnuWin32
versions of 
these, I believe.

>
> For your case, I recommend using the MSYS shell and
adding CPPFLAGS 
> and LDFLAGS configure options to find the GnuWin32
libraries you 
> installed.  It is likely that the GnuWin32 library DLLs
will also need 
> to be in the MSYS executable search path (PATH
environment variable).

I tried this, and got the following strange output:

johnSQUEAK2 ~/GraphicsMagick-1.1.10
$ echo $PATH
.:/usr/local/bin:/mingw/bin:/bin:/c/program 
files/graphicsmagick-1.1.10-q16:/c/program 
files/imagemagick-6.3.7-q16:/c/GTK/bin:/c/Tcl/bin:/c/WINDOWS
/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/c/Program 
Files/Subversion/bin:.:/c/Python25:/c/Python25/scripts:/c/Pr
ogram 
Files/GnuWin32/bin:/mingw/swigwin-1.3.31

johnSQUEAK2 ~/GraphicsMagick-1.1.10
$ echo $LD_LIBRARY_PATH
/mingw/lib:/c/Program Files/GnuWin32/lib

johnSQUEAK2 ~/GraphicsMagick-1.1.10
$ echo $CPPFLAGS
-Ic:Program FilesGnuWin32include

johnSQUEAK2 ~/GraphicsMagick-1.1.10
$ ./configure --without-perl
configuring GraphicsMagick 1.1.10
checking build system type... i686-pc-mingw32
checking host system type... i686-pc-mingw32
checking target system type... i686-pc-mingw32
checking whether build environment is sane... yes
checking for a BSD-compatible install... /bin/install -c
checking for a thread-safe mkdir -p... /bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking for gcc... gcc
checking for C compiler default output file name...
configure: error: C compiler cannot create executables
See `config.log' for more details.


>
>> Is there any way that I can build GraphicsMagick
against these installed
>> libraries, or must I download and compile each of
those first? Can I put
>> in a vote for improving support of MinGW, perhaps
in the form of a
>> simple binary installer suitable for MinGW users?
>
> There is no such thing as a "simple binary
installer" due to the need 
> to satisfy the GPL license, and other licenses.

Are you sure about that? What about the binary installers
for Visual C++ 
users? If it is legal to provide binaries for use by Visual
C++ users, 
presumably it is just as feasible to provide this for MinGW
users? Or 
are you just saying that the installers must provide a means
for the 
users to obtain the source code, accept license conditions,
etc?

>
>> Note, for example, that another graphics library,
GD, is available for
>> direct use in very convenient form here:
>> http:
//gnuwin32.sourceforge.net/packages/gd.htm
>
> Yes, this package is built by the same anonymous person
(persons?) who 
> builds the other GnuWin32 packages.  It is natural that
it plays well 
> with GnuWin32.

Perhaps one of the nice things about GD is that it is pure C
so it 
avoids all the annoying C++ ABI incompatibility nonsense.
Perhaps that 
same GD DLL can be used by both Visual C++ and GCC users --
I'm not sure.

Natural, but also wonderful. It would be great if
GraphicsMagick could 
acheive the same download-and-go convenience. Let's see what
we can do.

Cheers
JP


------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Graphicsmagick-help mailing list
Graphicsmagick-helplists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gra
phicsmagick-help

On Tue, 27 Nov 2007, John Pye wrote:
>
> I have had experience linking against GnuWin32
libraries using MSYS and 
> SCons. It all works fine, so I am certain that it is
possible to make use of 
> those libraries from GCC on MinGW. Perhaps some issues
with unix/windows path 
> syntax, but that is all handled my MSYS and shouldn't
affect anything at the 
> level of GCC/G++.

Right.

> If that is the case, can I suggest that you do a big
build as follows, and 
> make a tarball of the result?
>
> This would be sufficient to create a binary that other
developers like me 
> could make use of, without the need for me to go
through the job of 
> downloading libping, libtiff, etc. I could use the
GnuWin32 versions of 
> these, I believe.

For any of the 3rd party libraries which are GPL or LGPL, I
would need 
to then arrange to distribute the exact source for those
libraries in 
order to satisfy the license.  This is what GnuWin32 happens
to do.

> johnSQUEAK2 ~/GraphicsMagick-1.1.10
> $ echo $CPPFLAGS
> -Ic:Program FilesGnuWin32include

Try to avoid using any paths which include spaces.  Paths
with spaces 
often blow up due to the many shell substitutions which
occur in 
configure and libtool.  One argument then becomes two, and
there is a 
command line syntax error.

> checking for C compiler default output file name...
> configure: error: C compiler cannot create executables
> See `config.log' for more details.

What was the error reported in config.log?  I bet it has to
do with 
spaces in arguments.

> Are you sure about that? What about the binary
installers for Visual C++ 
> users? If it is legal to provide binaries for use by
Visual C++ users, 
> presumably it is just as feasible to provide this for
MinGW users? Or are you

It is legal to provide binaries for Visual C++ users since
we take 
care to provide the full sources as was used for the build. 
We could 
do this for MinGW as well but there is a lot less popular
demand and 
MinGW users usually expect to do a bit more work.

Maintaining the Windows build already consumes 4X the time
that I 
spend on all Unix platforms combined.  It is very time
consuming and 
the biggest impedement to more frequent GraphicsMagick
releases.

> just saying that the installers must provide a means
for the users to obtain 
> the source code, accept license conditions, etc?

GPL/LGPL does not actually require that installers obtain
acceptance 
of license conditions.  It does require providing source
code for the 
complete application (including non-GPL bits) except for
standard OS 
parts like the standard C library.

> Natural, but also wonderful. It would be great if
GraphicsMagick could 
> acheive the same download-and-go convenience. Let's see
what we can do.

I agree.  We need a volunteer to take charge of this task
for MinGW. 
Are you volunteering?

Bob
======================================
Bob Friesenhahn
bfriesensimple.dallas.tx.us, http://w
ww.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMag
ick.org/


------------------------------------------------------------
-------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Graphicsmagick-help mailing list
Graphicsmagick-helplists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gra
phicsmagick-help

Hi Bob,

Bob Friesenhahn wrote:
> On Tue, 27 Nov 2007, John Pye wrote:
>
>> If that is the case, can I suggest that you do a
big build as 
>> follows, and make a tarball of the result?
>>
>> This would be sufficient to create a binary that
other developers 
>> like me could make use of, without the need for me
to go through the 
>> job of downloading libping, libtiff, etc. I could
use the GnuWin32 
>> versions of these, I believe.
>
> For any of the 3rd party libraries which are GPL or
LGPL, I would need 
> to then arrange to distribute the exact source for
those libraries in 
> order to satisfy the license. This is what GnuWin32
happens to do.

My reading of GPL (it's been a while) was that you were
required to give 
access to people wanting your sources, but you're not
required to make 
them instantly available. So my believe is that it's OK to
say "I have 
used the source code from the libpng, libtiff and libwmf
projects, and 
I'll send it to you if you ask me to, but please first try
[whatever web 
page] and follow the links from there".

>
>> johnSQUEAK2 ~/GraphicsMagick-1.1.10
>> $ echo $CPPFLAGS
>> -Ic:Program FilesGnuWin32include
>
> Try to avoid using any paths which include spaces.
Paths with spaces 
> often blow up due to the many shell substitutions which
occur in 
> configure and libtool. One argument then becomes two,
and there is a 
> command line syntax error.

Worked much better. I have had success with the following
sequence of 
commands:

tar jxvf GraphicMagick-1.1.10.tar.bz2
LDFLAGS="-Lc:/Progra~1/GnuWin32/lib" ./configure
--without-perl 
--enable-static=no --enable-shared=yes
--prefix=/c/Progra~1/GnuWin32/
make
make DESTDIR=/home/john/magick_root/ install

The result of this is a bunch of files that are located
inside 
~/magick_root/c/ that I can zip up then unzip in my root
directory as a 
way of installing GraphicsMagick under the GnuWin32 path.

It all built OK, and appears to run (gm -help works, anyway
. I
will 
do some more testing.

Worth pointing out that this *did not* work with latest
ImageMagick, 
which gave some error about failing to find a symbol for
something to do 
with 'mogrify'.

>
>> checking for C compiler default output file
name...
>> configure: error: C compiler cannot create
executables
>> See `config.log' for more details.
>
> What was the error reported in config.log? I bet it has
to do with 
> spaces in arguments.

That was it. Fixed by using 'Progra~1' instead of 'Program
Files'.

>
>> Are you sure about that? What about the binary
installers for Visual 
>> C++ users? If it is legal to provide binaries for
use by Visual C++ 
>> users, presumably it is just as feasible to provide
this for MinGW 
>> users? Or are you
>
> It is legal to provide binaries for Visual C++ users
since we take 
> care to provide the full sources as was used for the
build. We could 
> do this for MinGW as well but there is a lot less
popular demand and 
> MinGW users usually expect to do a bit more work.
>
> Maintaining the Windows build already consumes 4X the
time that I 
> spend on all Unix platforms combined. It is very time
consuming and 
> the biggest impedement to more frequent GraphicsMagick
releases.

Maintaining releases *can* be slow. FWIW I find maintaining
MinGW 
releases easier because there is more common ground with
Linux...

>
>> just saying that the installers must provide a
means for the users to 
>> obtain the source code, accept license conditions,
etc?
>
> GPL/LGPL does not actually require that installers
obtain acceptance 
> of license conditions. It does require providing source
code for the 
> complete application (including non-GPL bits) except
for standard OS 
> parts like the standard C library.

See above

>
>> Natural, but also wonderful. It would be great if
GraphicsMagick 
>> could acheive the same download-and-go convenience.
Let's see what we 
>> can do.
>
> I agree. We need a volunteer to take charge of this
task for MinGW. 
> Are you volunteering?

I will endeavour to package the results of my current work
in some kind 
of reusable form. Whether I can make the time to provide
ongoing support 
I can't say just yet.

Cheers
JP


------------------------------------------------------------
-------------
SF.Net email is sponsored by: The Future of Linux Business
White Paper
from Novell.  From the desktop to the data center, Linux is
going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Graphicsmagick-help mailing list
Graphicsmagick-helplists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gra
phicsmagick-help

On Wed, 28 Nov 2007, John Pye wrote:
>> For any of the 3rd party libraries which are GPL or
LGPL, I would need to 
>> then arrange to distribute the exact source for
those libraries in order to 
>> satisfy the license. This is what GnuWin32 happens
to do.
>
> My reading of GPL (it's been a while) was that you were
required to give 
> access to people wanting your sources, but you're not
required to make them 
> instantly available. So my believe is that it's OK to
say "I have used the 
> source code from the libpng, libtiff and libwmf
projects, and I'll send it to 
> you if you ask me to, but please first try [whatever
web page] and follow the 
> links from there".

This sort of approach is best left to commercial enterprises
with a 
support staff.  For a free open source package like
GraphicsMagick it 
is much easier to simply put all files out for ftp.  This
way it is 
only necessary to offer source packages which support the
current 
binary release packages.  If a binary release package is
retired from 
the ftp site, then any outdated source packages can be
retired at the 
same time and there is no further obligation.

In other words, if pre-built MinGW binaries are supported,
then it is 
easiest to have a 'mingw' directory on the ftp site, and
include any 
GnuWin32 packages (binaries + sources) there as were
retrieved from 
the GnuWin32 site.  If the package requires additional
modification to 
work with GM, then the version modified for GM needs to be
offered. 
If a binary installer is provided, then the script for the
binary 
installer needs to be provided.

> It all built OK, and appears to run (gm -help works,
anyway . I will do

> some more testing.

A good sanity check is to execute commands like

   gm convert -list formats
   gm convert -list fonts
   gm convert -list colors
   gm convert -list delegates
   gm convert -list magic

since if these work then the configuration mechanism must be
sane.

> Worth pointing out that this *did not* work with latest
ImageMagick, which 
> gave some error about failing to find a symbol for
something to do with 
> 'mogrify'.

That does not surprise me.

>> Maintaining the Windows build already consumes 4X
the time that I spend on 
>> all Unix platforms combined. It is very time
consuming and the biggest 
>> impedement to more frequent GraphicsMagick
releases.
>
> Maintaining releases *can* be slow. FWIW I find
maintaining MinGW releases 
> easier because there is more common ground with
Linux...

Yes.  As it turns out, most people who develop software
under Windows 
are using the Microsoft compiler and IDE ("Visual
Studio").  This is 
even more true now that it is possible to create a mostly
working 
development environment (except for ATL and MFC) with free
downloads 
("Visual Studio Express").

If Visual Studio was not the current "standard"
then I would be quite 
happy to use Unix style build practices since Visual Studio
consumes 
lots of time.  Visual Studio would be easier to deal with if
each 
release of Visual Studio wasn't incompatible with prior
releases. 
Each release of Visual Studio uses a substantially different
project 
definition format, and the "promise" offered by
XML has not been 
realized at all.

There are several wrappers available which makes MSVC work
more like a 
Unix compiler so that it can be used in an autotools type
build 
environment.  I have never tried any of these.  Work has
also been 
done to allow autotools to use MSVC directly but this work
is not yet 
incorporated in a release.

>> I agree. We need a volunteer to take charge of this
task for MinGW. Are you 
>> volunteering?
>
> I will endeavour to package the results of my current
work in some kind of 
> reusable form. Whether I can make the time to provide
ongoing support I can't 
> say just yet.

Since it seems that it was actually not very difficult to
build using 
GnuWin32 packages, an alternative is to contribute some good

documentation for the process so that other people can use
the same 
procedure.  Yet another approach is to lobby the GnuWin32
project to 
offer a pre-built GraphicsMagick so that this project does
not need to 
worry about it at all.

Bob
======================================
Bob Friesenhahn
bfriesensimple.dallas.tx.us, http://w
ww.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMag
ick.org/


------------------------------------------------------------
-------------
SF.Net email is sponsored by: The Future of Linux Business
White Paper
from Novell.  From the desktop to the data center, Linux is
going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Graphicsmagick-help mailing list
Graphicsmagick-helplists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gra
phicsmagick-help

Hi Bob

I have completed a GraphicsMagick-1.1.10 installer that
works for me on
Windows. I have tested the 'gm convert -list' commands that
you listed,
and they seem to report favourably.

You can get both my binary and my build scripts from this
wiki page:
http://ascendwiki.cheme.cmu.edu/Building_Graphic
sMagick_on_MinGW

The key issue with the installer as it stands is that the
GraphicsMagick++-config and GraphicsMagick-config scripts
contain paths
encoded in MSYS format. When using SCons (my preferred build
tool), I
need access to scripts like that, but with paths encoded in
native
Windows format. Also, when using an installer such as this,
it's
preferable to allow the user to select where they will
install stuff ,
at install-time. So there shouldn't be any hardcoded paths.
I have
previously implemented a solution to this problem for
another project,
perhaps it might be something to consider for GraphicsMagick
also. See here:

htt
p://ascendcode.cheme.cmu.edu/viewvc.cgi/code/branches/extfn/
ascend-config.in?revision=1784&view=markup

Regardless of that issue, I still believe that this set of
binaries
should be of some use to MinGW users in current form.

I'd appreciate any comments on problems with the package as
it stands.
If you would like to incorporate the mingw-scripts stuff
into your
tarball, feel free. I'm happy to license them under the
GPL.

Cheers
JP


Bob Friesenhahn wrote:
> On Wed, 28 Nov 2007, John Pye wrote:
>>> For any of the 3rd party libraries which are
GPL or LGPL, I would
>>> need to then arrange to distribute the exact
source for those
>>> libraries in order to satisfy the license. This
is what GnuWin32
>>> happens to do.
>>
>> My reading of GPL (it's been a while) was that you
were required to
>> give access to people wanting your sources, but
you're not required
>> to make them instantly available. So my believe is
that it's OK to
>> say "I have used the source code from the
libpng, libtiff and libwmf
>> projects, and I'll send it to you if you ask me to,
but please first
>> try [whatever web page] and follow the links from
there".
>
> This sort of approach is best left to commercial
enterprises with a
> support staff. For a free open source package like
GraphicsMagick it
> is much easier to simply put all files out for ftp.
This way it is
> only necessary to offer source packages which support
the current
> binary release packages. If a binary release package is
retired from
> the ftp site, then any outdated source packages can be
retired at the
> same time and there is no further obligation.
>
> In other words, if pre-built MinGW binaries are
supported, then it is
> easiest to have a 'mingw' directory on the ftp site,
and include any
> GnuWin32 packages (binaries + sources) there as were
retrieved from
> the GnuWin32 site. If the package requires additional
modification to
> work with GM, then the version modified for GM needs to
be offered. If
> a binary installer is provided, then the script for the
binary
> installer needs to be provided.
>
>> It all built OK, and appears to run (gm -help
works, anyway . I
>> will do some more testing.
>
> A good sanity check is to execute commands like
>
> gm convert -list formats
> gm convert -list fonts
> gm convert -list colors
> gm convert -list delegates
> gm convert -list magic
>
> since if these work then the configuration mechanism
must be sane.
>
>> Worth pointing out that this *did not* work with
latest ImageMagick,
>> which gave some error about failing to find a
symbol for something to
>> do with 'mogrify'.
>
> That does not surprise me.
>
>>> Maintaining the Windows build already consumes
4X the time that I
>>> spend on all Unix platforms combined. It is
very time consuming and
>>> the biggest impedement to more frequent
GraphicsMagick releases.
>>
>> Maintaining releases *can* be slow. FWIW I find
maintaining MinGW
>> releases easier because there is more common ground
with Linux...
>
> Yes. As it turns out, most people who develop software
under Windows
> are using the Microsoft compiler and IDE ("Visual
Studio"). This is
> even more true now that it is possible to create a
mostly working
> development environment (except for ATL and MFC) with
free downloads
> ("Visual Studio Express").
>
> If Visual Studio was not the current
"standard" then I would be quite
> happy to use Unix style build practices since Visual
Studio consumes
> lots of time. Visual Studio would be easier to deal
with if each
> release of Visual Studio wasn't incompatible with prior
releases. Each
> release of Visual Studio uses a substantially different
project
> definition format, and the "promise" offered
by XML has not been
> realized at all.
>
> There are several wrappers available which makes MSVC
work more like a
> Unix compiler so that it can be used in an autotools
type build
> environment. I have never tried any of these. Work has
also been done
> to allow autotools to use MSVC directly but this work
is not yet
> incorporated in a release.
>
>>> I agree. We need a volunteer to take charge of
this task for MinGW.
>>> Are you volunteering?
>>
>> I will endeavour to package the results of my
current work in some
>> kind of reusable form. Whether I can make the time
to provide ongoing
>> support I can't say just yet.
>
> Since it seems that it was actually not very difficult
to build using
> GnuWin32 packages, an alternative is to contribute some
good
> documentation for the process so that other people can
use the same
> procedure. Yet another approach is to lobby the
GnuWin32 project to
> offer a pre-built GraphicsMagick so that this project
does not need to
> worry about it at all.
>
> Bob
> ======================================
> Bob Friesenhahn
> bfriesensimple.dallas.tx.us,
> http://w
ww.simplesystems.org/users/bfriesen/
> GraphicsMagick Maintainer, http://www.GraphicsMag
ick.org/
>


------------------------------------------------------------
-------------
SF.Net email is sponsored by: The Future of Linux Business
White Paper
from Novell.  From the desktop to the data center, Linux is
going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Graphicsmagick-help mailing list
Graphicsmagick-helplists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gra
phicsmagick-help

On Thu, 29 Nov 2007, John Pye wrote:
> I have completed a GraphicsMagick-1.1.10 installer that
works for me on
> Windows. I have tested the 'gm convert -list' commands
that you listed,
> and they seem to report favourably.

Good!

> The key issue with the installer as it stands is that
the
> GraphicsMagick++-config and GraphicsMagick-config
scripts contain paths
> encoded in MSYS format. When using SCons (my preferred
build tool), I
> need access to scripts like that, but with paths
encoded in native
> Windows format. Also, when using an installer such as
this, it's
> preferable to allow the user to select where they will
install stuff ,
> at install-time. So there shouldn't be any hardcoded
paths. I have

I am not sure what to do about the GraphicsMagick++-config
and 
GraphicsMagick-config script paths.  It seems impossible to
please 
everyone.

If you pass the --disable-installed option to configure,
then 
GraphicsMagick should not include any hard-coded paths and
will find 
its components at run-time using an algorithm.  This is how
the static 
Windows build is prepared.  With this approach, any
application using 
the GraphicsMagick libraries needs to take care to pass a
suitable 
argument to InitializeMagick() so that it is possible to
find the 
components.  It is easiest if the GraphicsMagick files live
in the 
same directory as the dependent application.

> I'd appreciate any comments on problems with the
package as it stands.
> If you would like to incorporate the mingw-scripts
stuff into your
> tarball, feel free. I'm happy to license them under the
GPL.

GraphicsMagick itself uses a MIT X11 style license.  The
reason why I 
often mention GPL is that some of the optional 3rd party
libraries are 
LGPL or GPL and so a binary build using those libraries
needs to be 
handled according to LGPL or GPL distribution terms.

Bob
======================================
Bob Friesenhahn
bfriesensimple.dallas.tx.us, http://w
ww.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMag
ick.org/


------------------------------------------------------------
-------------
SF.Net email is sponsored by: The Future of Linux Business
White Paper
from Novell.  From the desktop to the data center, Linux is
going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Graphicsmagick-help mailing list
Graphicsmagick-helplists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gra
phicsmagick-help

On Thu, 29 Nov 2007, John Pye wrote:
> Hmm... I have already found some problems with some
simple tests. I
> can't seem to link against the files in their installed
locations. Any
> suggsetions on how to fix this? Could it be that
there's some problem
> with the linking of the c:Program
> FilesGraphicsMagick-1.1.10liblibGraphicsMagick.dll.a
file and the
> c:Program
FilesGraphicsMagick-1.1.10binlibGraphicsMagick.dll
files?
> I'm thinking of ldconfig on Linux, is there something
similar at play
> here? Is it possible that the 'make DESTDIR' trick that
I used doesn't
> work correctly on Windows?

I don't know the exact cause of the linkage problem that you
are 
seeing, but please double check that you are using build
options 
suggested by

   GraphicsMagick++-config --cppflags

DESTDIR only influences where files are copied.  I don't see
the 
compiler complaining that it can't find a library so there
is 
likely something wrong with how you are building your own
.cpp file.

There is the possibility that the DLL files need to be in
your 
executable search path in order for GCC to decide to use
them.

If necessary, pass the -v option to GCC so you can see what
it is 
really doing.

Bob
======================================
Bob Friesenhahn
bfriesensimple.dallas.tx.us, http://w
ww.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMag
ick.org/


------------------------------------------------------------
-------------
SF.Net email is sponsored by: The Future of Linux Business
White Paper
from Novell.  From the desktop to the data center, Linux is
going
mainstream.  Let it simplify your IT future.
http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4
_______________________________________________
Graphicsmagick-help mailing list
Graphicsmagick-helplists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gra
phicsmagick-help