On Wednesday May 20 2015 12:11:08 Clemens Lang wrote:
Yes, we would have to revbump all dependents of the jpeg port if we do
this. Since it is unlikely that mozjpeg and libjpeg-turbo will ever
implement the changes to become compatible with libjpeg.9.dylib there is
no way to avoid the rebuild
On Wednesday May 20 2015 12:11:08 Clemens Lang wrote:
How do libjpeg-turbo and mozjpeg compare except in the latter's features to
create slightly smaller files (at what computing cost)?
I guess having the choice between mozjpeg and libjpeg-turbo would be
possible using the path dependency then.
Hi,
- On 20 May, 2015, at 12:31, René J.V. Bertin rjvber...@gmail.com wrote:
There are (probably) a number of huge ports that would have to be rebuilt,
among
the already huge number.
Yes, equally large as the number of ports we had to revbump when libjpeg was
updated to ship
On Wednesday May 20 2015 13:31:53 Clemens Lang wrote:
None of those are valid options. Nobody guarantees libjpeg.9.dylib will load
correctly into a binary compiled against libjpeg.8.dylib and vice-versa.
That's what I'm planning to verify, at least the vice-versa. The 9-into-8
question is
Hi,
- On 20 May, 2015, at 13:42, René J.V. Bertin rjvber...@gmail.com wrote:
None of those are valid options. Nobody guarantees libjpeg.9.dylib will load
correctly into a binary compiled against libjpeg.8.dylib and vice-versa.
That's what I'm planning to verify, at least the vice-versa.
Hi,
Updating port:LibVNCServer yesterday I was reminded of libjpeg-turbo, which
supposedly is
- 2-4x faster than the regular, scalar, libjpeg (something that ought to
benefit VNC)
- a drop-in replacement
Can anyone confirm those claims? I think it's rather safe to assume the 2nd
claim is
Hi,
- On 20 May, 2015, at 09:46, René J.V. Bertin rjvber...@gmail.com wrote:
Can anyone confirm those claims? I think it's rather safe to assume the 2nd
claim is true because on my Ubuntu rigs I have the turbo variant installed
instead of the scalar version, and everything seems to work
On 2015-05-20 12:49, René J.V. Bertin wrote:
On Wednesday May 20 2015 12:11:08 Clemens Lang wrote:
How do libjpeg-turbo and mozjpeg compare except in the latter's
features to create slightly smaller files (at what computing cost)?
http://www.libjpeg-turbo.org/About/Mozjpeg
In short: mozjpeg
On Wednesday May 20 2015 14:09:31 Clemens Lang wrote:
Feel free to improve the code that handles the viral spreading of universal
variants in base then.
The biggest problem ports are or provide libraries, so they'll have to be
universal unless I'd decide to use only i386 ports.
Besides, I've
Anyway, has anyone built libjpeg-turbo +universal lately? The i386 configure
invokes the nasm test as if for x86_64, which evidently leads to an error...
R.
___
macports-users mailing list
macports-users@lists.macosforge.org
ping
On Apr 26 19:40:17, nore...@macports.org wrote:
#46947: sox: please update to @14.4.2
-+
Reporter: mopihopi@??? | Owner: hans@???
Type: update | Status: new
Priority: Normal | Milestone:
Component:
On Wednesday May 20 2015 14:09:31 Clemens Lang wrote:
I trhink libjpeg.8.dylib will not load into a process compiled against
libjpeg.9.dylib because of incompatible library version numbers, but feel free
to try.
Someone had to try:
Indeed, no worky. Even after tweaking the compatibility
On May 20, 2015, at 6:31 AM, René J.V. Bertin rjvber...@gmail.com wrote:
As a related question: libjpeg-turbo depends on port:nasm, but I cannot get
it NOT to insist on reinstalling nasm+universal, not even using a
path:${prefix}/bin/nasm style dependency. How to get around that? Evidently
On Wednesday May 20 2015 13:54:42 Lawrence Velázquez wrote:
The nasm port doesn't install any libraries or headers, so it should be
setting installs_libs no to disable architecture checks. I just corrected
this.
https://trac.macports.org/changeset/136524
Ah, thanks. I planned to verify
14 matches
Mail list logo
