Opened 15 years ago

Closed 14 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 Carsten 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@… 15 years ago.
jpeg.diff (260.7 KB) - added by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez) 15 years ago.

Download all attachments as: .zip

Change History (13)

Changed 15 years ago by nox@…

Attachment: jpeg-7.diff added

comment:1 Changed 15 years ago by 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

comment:2 in reply to:  1 Changed 15 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 15 years ago by ryandesign (Ryan Carsten Schmidt)

Cc: ryandesign@… added

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

Attachment: jpeg.diff added

comment:4 Changed 15 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 15 years ago by MarcusCalhoun-Lopez (Marcus Calhoun-Lopez)

Cc: mcalhoun@… added

Cc Me!

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

comment:7 Changed 15 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 15 years ago by 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?

comment:9 Changed 15 years ago by rmsfisher@…

Cc: rmsfisher@… added

Cc Me!

comment:10 Changed 14 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 14 years ago by jmroot (Joshua Root)

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