Log file Viewer

[07:30:22] <jeremy_carroll_> question. How would I build PIL against mozjpeg? I tried setting JPEG_ROOT to the path where I build the .so modules for mozjpeg. It's just not respecting that path while creating _imaging.so

[10:42:26] <travis-ci> hugovk/Pillow#715 (anntzer-tiff-resolution - 800480d : Antony Lee): The build passed.

[10:42:26] <travis-ci> Change view : https://github.com/hugovk/Pillow/commit/800480db526b

[10:42:26] <travis-ci> Build details : http://travis-ci.org/hugovk/Pillow/builds/43699714

[11:10:58] <travis-ci> hugovk/Pillow#716 (test_psdraw - 385ad47 : hugovk): The build failed.

[11:10:58] <travis-ci> Change view : https://github.com/hugovk/Pillow/compare/9581da4daa54...385ad47a9be0

[11:10:58] <travis-ci> Build details : http://travis-ci.org/hugovk/Pillow/builds/43703760

[11:24:02] <travis-ci> hugovk/Pillow#717 (test_psdraw - 6da05b4 : hugovk): The build is still failing.

[11:24:02] <travis-ci> Change view : https://github.com/hugovk/Pillow/compare/385ad47a9be0...6da05b40269e

[11:24:02] <travis-ci> Build details : http://travis-ci.org/hugovk/Pillow/builds/43705091

[16:56:07] <wiredfool> jeremy_carroll_: Not totally sure -- it's a murky part of the setup as to which of two possible matching libraries it will use if they're both found in the include/linking path.

[16:56:52] <jeremy_carroll_> wiredfool: Thanks for the response. I was playing around this morning. Found out that JPEG_ROOT really did not matter. It was using the OS ld.so.cache to find libjpeg. So basically I added mozjpeg to the ldconfig. Then it found it.

[16:57:00] <wiredfool> It's possible that you could prefix the include/link pathby using the CFLAGS and LDFLAGS environment variables, and

[16:57:02] <wiredfool> oh

[16:57:42] <jeremy_carroll_> Ex: create `/etc/ld.so.conf.d/mozjpeg.conf` with the path to libjpeg created by mozjpeg. Then run `ldconfig` to rebuild the cache. Then compile. Bingo.

[16:58:34] <wiredfool> That's something that would be useful to have in the docs somewhere

[16:58:56] <jeremy_carroll_> Yeah. It uses the local LD cache to find most libraries during compile time. So if libjpeg exists in the system path, it will add it.

[16:59:02] <wiredfool> and the foo_root stuff is a holdover from PIL, I'm not sure it's actualyl necessary anymore.

[16:59:11] <jeremy_carroll_> wiredfool: exactly.

[16:59:22] <wiredfool> it == modern linux system?

[16:59:28] <jeremy_carroll_> Yeah. Ubuntu 12.04 / 14.04

[17:00:35] <wiredfool> I'm sure the next question would be 'what if I don't have root?'

[17:00:41] <jeremy_carroll_> That's a great questino.

[17:00:50] <jeremy_carroll_> This would not work in that case.

[17:01:19] <wiredfool> yeah

[17:02:27] <wiredfool> as the last question on mozjpeg was from someone who was using shared hosting and it was installed in /opt or something.

[17:02:59] <jeremy_carroll_> Yeah. Exactly. Then you would need something to add it to the path. The issue I had was even with JPEG_ROOT, the original libjpeg.so.62 was in the system path. It was being preferred over mozjpeg.

[17:03:23] <jeremy_carroll_> So when you `ldd ./build/lib.linux-x86_64-2.7/_imaging.so`, it was using the local system libjpeg provided by libtool.

[17:03:46] <jeremy_carroll_> Could not find a way around it

[17:04:01] <wiredfool> that's where LDFLAGS would come in, I think

[17:04:06] <jeremy_carroll_> +1.

[17:04:22] <wiredfool> assuming that it prepends, and the linker searches in order

[17:04:24] <jeremy_carroll_> Probably set it manually in the flags to compile against.

[17:04:46] <jeremy_carroll_> I did try hacking setup.py code to have the JPEG_ROOT -I"/path" higher in the path list. No effect.

[17:04:54] <jeremy_carroll_> GCC still did not respect it.