Re: [Swftools-common] Undefined symbols _PrintGifError when building swf

[List_Subs]

On Thu, 31 May 2012 00:41:58 -0500
Ryan Schmidt <address@hidden> wrote:

> Chris wrote:
> > I'm not a Mac user, but,
> > 
> >    http://www.apple.com/opensource/
> > 
> > states giflib as being at 4.1.6.
> > 
> > I have 0.9.2 happily compiled against the same version.
> > 
> > Is it really essential for you use 4.2.0? 
>  
> Hello, I'm the maintainer of giflib in MacPorts, and I'm joining this
> conversation because it seems to have stagnated without a solution.

Welcome then Ryan.  Stagnate, unfortuately, these things sometimes
do. ;o)

> This is not a Mac-specific issue; it affects any user who has
> upgraded to giflib 4.2.0, which is the latest stable version of
> giflib is that has been released by its developers:
> 
> http://sourceforge.net/projects/giflib/

I was aware of the above, yes.  My suggestion of a downgrade to
4.1.6 was meant as a temporary solution, not a permanent fox. 

> As the maintainer of the port, I recently updated giflib in MacPorts
> to version 4.2.0, which prompted the above MacPorts bug report, to
> which I replied that it was not our problem to fix, which prompted
> Simon to write to this list. giflib 4.2.0 has removed the
> PrintGifError function; it cannot be used anymore. The giflib 4.2.0
> NEWS file states:
> 
> >   QuantizeBuffer(), GifQprintf(), PrintGifError(), GIF_ERROR() 
> >   and GIF_MESSAGE() have been removed from the core library.  
> >   They were used only by the utilities.
> 
> This implies the developer of giflib never intended these functions
> to be used by third parties. Any further questions about why these
> functions were removed should be directed to the developer of giflib,
> but the fact is that they have been removed and cannot be used
> anymore.

I am not familiar with giflib internals, however, as with any OSS code,
if functions are available to called ( and documented to be so), then I
personally see no reason why they should not be used.  Implication and
assumption should never come in to this.  If certain things are meant
for internal use only, then they should be firmly documented as such..
'..if you use x,y, or z, then you do so at your own risk.  We take  no
responsibility for things breaking with a future release.'

So, rather than just rip exisitng functions out, always a sure sign that
something will break,  the wiser and more sensible course of action is
to phase changes out by issuing a warning that certain things are to
be removed in a future version, and thus will not longer work.  If that
course of action was taken here, then I agree, the swftools maintainer
was not paying attention and premptive measures should have been taken.
If it wasn't, then the gif library maintainers should have been more
retrospect, and ought to be so in the future.

> The developers of swftools should update swftools to be compatible
> with the latest stable version of giflib by no longer attempting to
> use this function.

Now the issue has been flagged, I agree.  I am sure the issue will be
rectified shortly.
 
> Once that happens, we can update the swftools port in MacPorts to
> include that fix, so that MacPorts users can once again install
> swftools; until that time, they will not be able to do so.

Quite.

I see the swftools 'port' currently has no maintainer.  But, the port
page itself,

https://trac.macports.org/browser/trunk/dports/graphics/swftools/Portfile

contains all the necessary information.  For that, thank you.

Regards,


Chris.