jpeg update to 7

[nox@…]

Changes:

• Update to 7.
• Remove obsolete autotools patches.
• Remove droppatch.tar.gz (now in jpeg itself).

[nerdling (Jeremy Lavergne)]

Got a few errors from configure. it seems that ldflags and cppflags aren't always there?

Error: Target org.macports.configure returned: can't read "configure.ldflags": no such variable
Error: Target org.macports.configure returned: can't read "configure.cppflags": no such variable

[blb@…]

Replying to snc@…:

Got a few errors from configure. it seems that ldflags and cppflags aren't always there?

Error: Target org.macports.configure returned: can't read "configure.ldflags": no such variable Error: Target org.macports.configure returned: can't read "configure.cppflags": no such variable

That's a bug with 1.7 where doing something like

configure.ldflags-delete    -L${prefix}/lib

causes the variable to go away. See #17865 and #20145.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

In r54369, I committed ​jpeg.diff, which is just ​jpeg-7.diff
without an unnecessary master_sites and the following;

# See http://trac.macports.org/ticket/17865 and http://trac.macports.org/ticket/20145                                                                                                                    
# This can be removed when r44901 (http://trac.macports.org/changeset/44901) is released.                                                                                                                
configure.cppflags-append  {}                                                                                                                                                                            
configure.ldflags-append   {}

Unfortunately, such a change breaks all ports which depend on jpeg.

The first error is

dyld: Library not loaded: /opt/local/lib/libjpeg.62.dylib

An easy fix is:

post-destroot {
    ln -s libjpeg.dylib ${destroot}${prefix}/lib/libjpeg.62.dylib
}

The next problem is that the current version of ${prefix}/lib/libjpeg.7.dylib is 8.0.0 while the old ${prefix}/lib/libjpeg.62.dylib has a compatibility version of 63.0.0.
Since 7.0.0 < 63.0.0, an error ensues.

jpeg was returned to version 6b in r54372.

[MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Replying to mcalhoun@…:

The first error is dyld: Library not loaded: /opt/local/lib/libjpeg.62.dylib An easy fix is: post-destroot {

ln -s libjpeg.dylib ${destroot}${prefix}/lib/libjpeg.62.dylib

}

I found ​this page which implies there are dire consequences of creating such a symlink, but does not say what they are.

The next problem is that the current version of ${prefix}/lib/libjpeg.7.dylib is 8.0.0 while the old ${prefix}/lib/libjpeg.62.dylib has a compatibility version of 63.0.0. Since 7.0.0 < 63.0.0, an error ensues.

Has anyone contacted the developers of libjpeg to see what the heck they were thinking? :)

[tobypeterson]

It doesn't matter that 7 is less than 63, it only matters that it's different. Different compatibility version means dyld barfs, there's no lessthan/greaterthan check.

The new compatibility version is fine (much more sane), but we will need to bump the revision on every port that depends on jpeg. As far as I can tell, it's API-compatible, but it will still require clients to be rebuilt.

[ryandesign (Ryan Carsten Schmidt)]

Replying to toby@…:

It doesn't matter that 7 is less than 63, it only matters that it's different. Different compatibility version means dyld barfs, there's no lessthan/greaterthan check.

I was under the impression that that was exactly the point of having a compatibility version -- that a less-than/greater-than check was performed. The Fink project's documentation ​says it is so:

dyld generates a run-time error and terminates the program unless the loaded library version is equal to or newer than the one used during linking

This capability is demonstrably at work in tickets like #20959.

The new compatibility version is fine (much more sane), but we will need to bump the revision on every port that depends on jpeg. As far as I can tell, it's API-compatible, but it will still require clients to be rebuilt.

So, can we do this? Or is there something else preventing the update to jpeg 7?

[rmsfisher@…]

Cc Me!

[jmroot (Joshua Root)]

This would be a nice use case for #17473. Either way, we probably can't put off the upgrade forever?

[jmroot (Joshua Root)]

r61377