Legacy ImageMagick Discussions Archive

I successfully compiled my first application in windows today. I compiled IM 6.4.2 using mingw and the jpeg delegate. I compiled with the --disable-shared switch so I have completely standalone binaries... they appear to work great.

Now all I need to do is get the binaries down in size... by a couple of MB's or so would be great!

Anyone know how I can exclude unnecessary file formats (I only need bmp, jpeg, and the internal formats), and any other optional and/or unnecessary peices (the logo, help, etc.).

Thanks!

To remove a format, remove or comment out its Register and Unregister method calls in magick/static.c. Next, remove the build / link statements for the format in Makefile. Repeat for each format you do not want. You can completely remove the MagickWand (ImageMagick-6.4.2/wand) dependency if you toss the ttf and wmf coder modules.

You can completely remove the MagickWand (ImageMagick-6.4.2/wand) dependency if you toss the ttf and wmf coder modules.

I am guessing I need MagicWand to place text on the image (which is what I will be using the resulting program for)?

Thanks!

One other thing... what file formats are required internally... particularly for working with text.

Final Question... when you say to remove the build/link statements in the make file do you mean, for example for the "Art" format, to delete or comment out:

Magick___lib_libMagick___la_LINK = $(LIBTOOL) --tag=CXX \
$(AM_LIBTOOLFLAGS) $(LIBTOOLFLAGS) --mode=link $(CXXLD) \
$(AM_CXXFLAGS) $(CXXFLAGS) \
$(Magick___lib_libMagick___la_LDFLAGS) $(LDFLAGS) -o $@

Is there an easier way? I intend to remove anything that's not absolutely necessary, which means a lot of edits.

Please keep in mind that I'm not a developer.

The easiest method is to edit coders/Makefile.am but that would require that you regenerate the Makefile's with the latest release of autoconf / automake / libtool. Otherwise you will need to hand edit Makefile as you suggested. If you intend to generate a shared library version of ImageMagick, you could build the entire distribution and simply remove the coder.so and coder.la files that you don't want (e.g. art.so, art.la).

I have the latest autoconf, automake, and libtool... how do I generate the makefile... or is that complicated as well?

In reguards to my other questions... what shouldn't I remove (I simply want to insert text into an image and convert from jpg to bmp)? Do I need MagickWand for this?

To regenerate the Makefile, simply edit Makefile.am and then run the automake program.

MagickWand is not necessary to do what you want (insert text into an image and convert from jpg to bmp).

Sorry to resurrect an old thread... but I put the project aside for a while and now I want to complete it.

I successfully built a shared library version of IM with mingw and msys. It was hell but now I have a bunch of small .exe files and .dlls. However I don't think they know how to find each other.

My build line was: I did not do a make install as I am not sure I need to.

After resolving some issues with libraries (for example I needed to install gettext) I was able to get it to compile to shared libraries with the command above... but I can't figure out what to do with them.

I tried copying the .exe and .dll files into a folder but I just get a: whenever I try to run one of the .exe's

I haven't done a make install, but I don't think I should need to.

I am guessing there is a simple solution I am overlooking... like perhaps the coders need to be in a directory below the .exe's or something like that... but I can't figure out the order that the .exe files use to locate the .dlls

The fact that the command's error without any parameters tells me that their is an additional shared file, perhaps libMagickCore-1.dll, that the .exe must be able to access too.

Any help on using this build would be great!

Greetings,
I'll take a stab at answering both issues in this thread.
"Sorry to resurrect an old thread"...
I may be mistaken here, but I think the configure should have been: ...note the --disable-shared, and
--enable-static.
Reason being; you will be able to pack the whole group of compiled files into one
single directory/folder, rather than having them spread out in some "system specific"
layout. Also, you'll probably want to pay close attention to the "pathing" inside
the makefile - this is where the exe's will expect to find everything after they've been
built.

"Now all I need to do is get the binaries down in size..."
What you might want to look into here is an exe packer.
There are several available, and they all do a pretty good job at what they're
designed to do; pack exe files. What's more, they'll pack dll's and even make them
"hack proof", if you want. In any case, they will make the files smaller. The
only down-side to using one of these packers, is that there is a slightly longer delay
on initial execution. But it is so insignificant, that it's hardly worth mentioning.
Reason being; they need to UNpack themselves into memory. So, in case it isn't
already evident, the initial "stripping" they do, is fairly insignificant, so the majority of
the file is simply compressed - requiring it to be UNcompressed prior to
execution.
A search on sourceforge for "exe packer" will give you some of the "open sourced"
possibilities.

Best wishes.

--Chuck

P.S. I don't know what kind of resources your computer has. But you might want
to look into a VM (Virtual Machine), like VMware, or Virtual PC.
That way you could enjoy all the conveniences that *NIX users do. What's
more; if you installed FreeBSD, you could "cross compile" for Windows, right out
of the box.
Just thought it might be worth mentioning.

Charlie, thanks for the reply. The reason I used --enable-shared and --disable-static was because I wanted to create a shared library version. I used the --disable-installed so that the shared library version did not hard code the path to the libraries, but rather would look for them in the same folder or a subfolder of the executable.

The reason I did this is that I found it difficult to significantly reduce the size of the static binaries. I tried the described methods of removing different coders, but found that to be frustrating and would require a recompile if I later needed to use a different image format.

I was under the impression that doing a --disable-installed would allow me to place the .exe files and .dll files in the same folder and have everything work... but it doesn't. I am guessing that --disable-installed instead tells the .exe files to look in a subfolder of it's current location... but I cannot find any documentation of this, and I don't know the code well enough to determine where the .exe's are looking.

I am curious about the .exe packer idea... but keep in mind that I would like my solution to end up under a megabyte if possible... and all static binaries I have compiled weigh in at over 6MB. I doubt any amount of packing will reduce them that much.

I am a *nix user, except at work, however I am far from a developer and wouldn't know the first thing about cross compiling anything for windows on any flavor of *nix.

The final product must be small enough that I can copy it to a slow VPN users' computer in a logon script. Essentially, anything more than a MB is too large and will generate complaints from my users. My hope is that I can create a script that will generate a .BMP wallpaper containing informational text and graphics. I have explored every option that I can think of, and IM seems to be the only product that will meet my needs... if I could ever get it down to a manageable size.

Any other suggestions?

Hello jhfry.

I have to admit, I haven't developed anything on a "winboxen" for quite some time. So
the advice I shared was strictly from memory.

That being said. When I was developing, I always used alternatives to the M$ developer
tools, as well as anything else the required payment for their use. It was a huge
advantage, as the alternatives were far more "cutting edge" than the "pay for"
tools. They were also more familiar to me, as I had always been a UNIX (not SCO)
user first. I only used Windows because it was always broken, which made
it easy to make money from, because Windows users were always needing my services
to fix their problems.

Anyway, to the point...
You should be able to accomplish you're intended goal without too
much difficulty. But it will require a little "trial and error". This means,
even though you don't want to, you'll need to re-compile the source a 'couple
of times to reach the ultimate final goal - sorry.

When it's all said, and done. You should be able to pack the entire mess into
one single executable - really. This was a trick back in the old days
of C - not C++. We used overlays. It's a bit different now, but the principal
is still the same. I would recommend as a first step to experiment with the
packers available. To see which one gives you the best
results and to discover just how far you need to go. I'll see what I
have already on my spare Winboxen. I haven't fired it up for some time. But I'll
post back here with anything I might have to offer.

Till then, best wishes.

--Chuck

P.S. As memory serves, Aspack, and UPX should be good starting points for
packers.
Lemme know your results.

OK... Update and questions:

1. I managed to get the standalone shared library version working on windows... I used: Then I copied a minimal set of exe, dll, la, and XML files from /bin and /lib/* to my script folder. [/code]

2. Also I managed to shrink the size of the standlone executable built by commenting out the 4 line block for each of the coders I will not need in coders/makefile.am. Then I ran: The file is down to about 3MB from 6MB... but still looks for type.xml when working with text. Better, but not good enough!

Questions:

• How do I remove the need for MagickWand. I tried everything but I can't seem to get it to compile without MagickWand? It always fails trying to compile Animate.exe (which I do not need anyway).
• Is there anything besides coders and MagickWand that I can safely remove and how do I do it?
• Why is my standalone executable I created with the commands above still asking for type.xml. The ones included in the Ming32 download work without it.

[/color]

Thanks!

EDIT: Using UPX I was able to compress my convert.exe down from 3.09MB to 952KB... so I've reached my goal (Thanks for turning me on to EXE compression Charlie!)... but I would love to reduce that by a further 1/3 by removing the MagicWand dependency. In my situation smaller is better.

EDIT: Using UPX I was able to compress my convert.exe down from 3.09MB to 952KB... so I've reached my goal

Congratulations jhfry!

(Thanks for turning me on to EXE compression Charlie!)

Will you be hosting an awards ceremony for me?

but I would love to reduce that by a further 1/3 by removing the MagicWand dependency.

As memory serves, that's primarily designed as a hook for PHP. So you should have no
difficulties without it. But you knew that. My point being; you may be able to simply
remove the .dll file from your package - that is; delete it from your intended
ImageMagick folder. Try it, and see if IM complains. You might also have a look in the
configure script for indications of MagickWand && MagickWand++. I haven't looked at
the source for some time now. But a configure option such as: or might be all that it takes.

Why is my standalone executable I created with the commands above still asking for type.xml.

Here's a script that'll help you find everything related to type.xml: Simply save this script as findtypexml.sh, and drop it into your IM src
directory. If you make no changes to the above script, you'll end up
with a file named FOUND in the directory above your IM src directory.
It will contain a list of all the files that contain the word type.xml, and
a brief summary of the context. It might be biggish. A better solution might
be a PREFIX, or LIBDIR/CONFDIR option to the ./configure script. But I
don't have a copy of your version of the source to crack open, and look at.

HTH

--Chuck

P.S. If you're using the current version of UPX (3 something) you have the option of
stripping some of the header data during compression. This option may, or
may not work for you, as it isn't always possible to do this w/o
breaking the exe, or dll's. Try it on one, or both, to see if you can get away
with it. It'll save you some more in size.

charlie wrote:

but I would love to reduce that by a further 1/3 by removing the MagicWand dependency.

As memory serves, that's primarily designed as a hook for PHP. So you should have no
difficulties without it. But you knew that. My point being; you may be able to simply
remove the .dll file from your package - that is; delete it from your intended
ImageMagick folder. Try it, and see if IM complains. You might also have a look in the
configure script for indications of MagickWand && MagickWand++. I haven't looked at
the source for some time now. But a configure option such as:

Code: Select all

./configure -Dwithout-magickwand=true

or

Code: Select all

./configure -Dwithout-magickwand

might be all that it takes.

I wish there were an option in the config file... believe me, that's the first place I looked.

Deleting the libMagickWand-1.dll causes all of the .exe files to return a blank line and return to the prompt... not even an error message.

Magick - Can you help me with this, you told me it's possible!

charlie wrote:Here's a script that'll help you find everything related to type.xml:

I've already searched for all references to type.xml... but can't make heads or tails of it. I did prove that type.xml isn't required by the windows .exe builds by creating a blank file called type.xml. However if the file doesn't exist, the error is thrown. ARGH, should be so simple.

Magick - Help on this too please!

Thanks for all the input Charlie!