Build_Failure AMD64 freebsd 6.1

Post any defects you find in the released or beta versions of the ImageMagick software here. Include the ImageMagick version, OS, and any command-line required to reproduce the problem. Got a patch for a bug? Post it here.
Post Reply
User avatar
mi
Posts: 123
Joined: 2005-01-25T14:14:43-07:00
Contact:
Contact mi

Re: Build_Failure AMD64 freebsd 6.1

Post by mi »

Modules remain a problem, are marked as "broken" in the FreeBSD port, and are disabled by default. The problem may or may not be FreeBSD-specific, but the module-support in ImageMagick does not do you any good, so I have not bothered debugging it...
Top
User avatar
magick
Site Admin
Posts: 11064
Joined: 2003-05-31T11:32:55-07:00

Re: Build_Failure AMD64 freebsd 6.1

Post by magick »

We recommend the use of modules. It permits ImageMagick to dynamically load only those coders that are required at run time. We have not seen the exception you are receiving other than on FreeBSD. It is returned by lt_dlclose() from the GNU libtool ltdl.c module. The exception is a warning only so it should be safe to ignore.
Top
User avatar
mi
Posts: 123
Joined: 2005-01-25T14:14:43-07:00
Contact:
Contact mi

Re: Build_Failure AMD64 freebsd 6.1

Post by mi »

magick wrote:We recommend the use of modules. It permits ImageMagick to dynamically load only those coders that are required at run time.
And why is this better? Have you performed any tests on a modern OS -- such as Linux or BSD -- to determine, that there is any gain?

I would suspect a loss, actually. Linked-in modules themselves are very small. The actual backends are shared libraries, which are mapped in by the operating system's run-time linker. Being mmap-ed in, they are not actually read from disk until called...
magick wrote:It is returned by lt_dlclose() from the GNU libtool ltdl.c module. The exception is a warning only so it should be safe to ignore.
It reports an invalid handle -- that to me is an indication of memory corruption, actually. Or, maybe, a handle returned by the (real) dlopen is being closed by lt_dlclose (or the other way around)...
Top
User avatar
magick
Site Admin
Posts: 11064
Joined: 2003-05-31T11:32:55-07:00

Re: Build_Failure AMD64 freebsd 6.1

Post by magick »

ImageMagick includes a plug-in image filter system (see -process option) which is not enabled unless modules are enabled. In most cases people do not use plug-ins but we do like to have this option available to users if they need it.
Top
User avatar
mi
Posts: 123
Joined: 2005-01-25T14:14:43-07:00
Contact:
Contact mi

Re: Build_Failure AMD64 freebsd 6.1

Post by mi »

magick wrote:ImageMagick includes a plug-in image filter system (see -process option) which is not enabled unless modules are enabled. In most cases people do not use plug-ins but we do like to have this option available to users if they need it.
Oh, I see, so it is the functionality, that will be degraded without plugins - not performance... I'll look into it, then - I wish, this was the stated reason, rather than the claims of better performance.

Are there any filters bundled with ImageMagick distribution, or is this only intended for 3rd-party filters, if any? Can you name some of the existing ones?

FreeBSD port of ImageMagick never had the plugins enabled by default -- because some of the back-ends (like, most infamously, Jasper) would register their functions via atexit(), which lead to segfaults on exit (when the registered function is not available due to prior dlclose()). Apparently, Linux is more forgiving of such things, so you never noticed it before...

Now that Jasper is fixed, it may be possible to enable plugins. When FreeBSD's current port-freeze is over, I may be able to fix the plugins option.
Top
Post Reply

Return to “Bugs”