Opened 9 years ago

Closed 9 years ago

#20193 closed update (fixed)

jpeg update to 7

Reported by: nox@… Owned by: waqar@…
Priority: Normal Milestone:
Component: ports Version:
Keywords: Cc: ryandesign (Ryan Schmidt), MarcusCalhoun-Lopez (Marcus Calhoun-Lopez), rmsfisher@…, jmroot (Joshua Root)
Port: jpeg

Description

Changes:

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

Attachments (2)

jpeg-7.diff (260.2 KB) - added by nox@… 9 years ago.
jpeg.diff (260.7 KB) - added by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez) 9 years ago.

Download all attachments as: .zip

Change History (13)

Changed 9 years ago by nox@…

Attachment: jpeg-7.diff added

comment:1 Changed 9 years ago by nerdling (Jeremy L)

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

comment:2 in reply to:  1 Changed 9 years ago by 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.

comment:3 Changed 9 years ago by ryandesign (Ryan Schmidt)

Cc: ryandesign@… added

Changed 9 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Attachment: jpeg.diff added

comment:4 Changed 9 years ago by 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.

comment:5 Changed 9 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Cc: mcalhoun@… added

Cc Me!

comment:6 in reply to:  4 Changed 9 years ago by ryandesign (Ryan 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? :)

comment:7 Changed 9 years ago by 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.

comment:8 in reply to:  7 Changed 9 years ago by ryandesign (Ryan 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?

comment:9 Changed 9 years ago by rmsfisher@…

Cc: rmsfisher@… added

Cc Me!

comment:10 Changed 9 years ago by jmroot (Joshua Root)

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

comment:11 Changed 9 years ago by jmroot (Joshua Root)

Cc: jmr@… added
Resolution: fixed
Status: newclosed
Note: See TracTickets for help on using tickets.