third_party/libpng/README.chromium - Issue 2021403002: Update libpng to 1.6.22

Side by Side Diff: third_party/libpng/README.chromium

Issue 2021403002: Update libpng to 1.6.22 (Closed) Base URL: https://chromium.googlesource.com/chromium/src.git@master

Patch Set: Mac rebaselines Created 4 years, 6 months ago

Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.

Jump to:

View unified diff | Download patch

OLD	NEW
1 Name: libpng	1 Name: libpng

2 URL: http://libpng.org/	2 URL: http://libpng.org/

3 Version: 1.2.56	3 Version: 1.6.22

4 Security Critical: yes	4 Security Critical: yes

5 License: libpng license	5 License: libpng license

6 License Android Compatible: yes	6 License Android Compatible: yes

7	7

8 Description:	8 Description:

9 Updated to 1.2.56, no changes to the source files but all unneeded files	9 Updated to 1.6.22, stripped all unneeded files.

10 stripped.

11	10

12 Our custom configuration options are defined in pngusr.h. This was previously	11 - Use custom configuration file pnglibconf.h, which turns off all features that
	Nico 2016/06/03 20:27:45 aha; list that in the gyp / gn files then aha; list that in the gyp / gn files then msarett 2016/06/03 21:26:01 Done! Show quoted text On 2016/06/03 20:27:45, Nico wrote: > aha; list that in the gyp / gn files then Done!
13 called mozpngconf.h, which was copied from Mozilla and modified by Apple (hence	12 are not in use.

14 the wk_* names):	13 - Use custom prefix file pngprefix.h, which avoids namespace conflicts with

15 - Unset PNG_NO_READ_PACK on Android in pngusr.h, required by freetype to support	14 pdfium's copy of libpng.
	Nico 2016/06/03 20:27:45 i think pdfium is supposed to use chromium's libpn i think pdfium is supposed to use chromium's libpng when it's part of a chromium build and its own copy else. both copies should never compete with each other. msarett 2016/06/03 21:26:01 That seems to make sense. I did try to compile wi Show quoted text On 2016/06/03 20:27:45, Nico wrote: > i think pdfium is supposed to use chromium's libpng when it's part of a chromium > build and its own copy else. both copies should never compete with each other. That seems to make sense. I did try to compile without prefixing, and things failed to link due to namespace conflicts. So I decided to leave the prefixing as is for now. Nico 2016/06/03 21:36:49 What exactly fails? That sounds like something we Show quoted text On 2016/06/03 21:26:01, msarett wrote: > On 2016/06/03 20:27:45, Nico wrote: > > i think pdfium is supposed to use chromium's libpng when it's part of a > chromium > > build and its own copy else. both copies should never compete with each other. > > That seems to make sense. I did try to compile without prefixing, and things > failed to link due to namespace conflicts. So I decided to leave the prefixing > as is for now. What exactly fails? That sounds like something we should probably fix. msarett 2016/06/06 14:18:15 ../../third_party/binutils/Linux_x64/Release/bin/l Show quoted text On 2016/06/03 21:36:49, Nico wrote: > On 2016/06/03 21:26:01, msarett wrote: > > On 2016/06/03 20:27:45, Nico wrote: > > > i think pdfium is supposed to use chromium's libpng when it's part of a > > chromium > > > build and its own copy else. both copies should never compete with each > other. > > > > That seems to make sense. I did try to compile without prefixing, and things > > failed to link due to namespace conflicts. So I decided to leave the > prefixing > > as is for now. > > What exactly fails? ../../third_party/binutils/Linux_x64/Release/bin/ld.gold: error: obj/third_party/libpng/libpng_sources/png.o: multiple definition of 'png_access_version_number' ../../third_party/binutils/Linux_x64/Release/bin/ld.gold: obj/third_party/pdfium/third_party/fx_lpng/png.o: previous definition here ../../third_party/binutils/Linux_x64/Release/bin/ld.gold: error: obj/third_party/libpng/libpng_sources/png.o: multiple definition of 'png_build_gamma_table' ../../third_party/binutils/Linux_x64/Release/bin/ld.gold: obj/third_party/pdfium/third_party/fx_lpng/png.o: previous definition here ../../third_party/binutils/Linux_x64/Release/bin/ld.gold: error: obj/third_party/libpng/libpng_sources/png.o: multiple definition of 'png_calculate_crc' ../../third_party/binutils/Linux_x64/Release/bin/ld.gold: obj/third_party/pdfium/third_party/fx_lpng/png.o: previous definition here ../../third_party/binutils/Linux_x64/Release/bin/ld.gold: error: obj/third_party/libpng/libpng_sources/png.o: multiple definition of 'png_check_IHDR' ../../third_party/binutils/Linux_x64/Release/bin/ld.gold: obj/third_party/pdfium/third_party/fx_lpng/png.o: previous definition here ../../third_party/binutils/Linux_x64/Release/bin/ld.gold: error: obj/third_party/libpng/libpng_sources/png.o: multiple definition of 'png_chunk_unknown_handling' ../../third_party/binutils/Linux_x64/Release/bin/ld.gold: obj/third_party/pdfium/third_party/fx_lpng/png.o: previous definition here ../../third_party/binutils/Linux_x64/Release/bin/ld.gold: error: obj/third_party/libpng/libpng_sources/png.o: multiple definition of 'png_colorspace_set_ICC' etc... Show quoted text > That sounds like something we should probably fix. Agreed. I'm guessing we would need to modify the pdfium build files to only compile their own copy of libpng when not on Chrome? Can I handle this in a follow-up change?
16 color glyphs.	15 - Configures custom png chunk user limits (crbug.com/117369) in pnglibconf.h.

17 - Configure PNG chunk user limits (crbug.com/117369)	16 - Fix for potential memory leak from upstream:

	17 https://github.com/glennrp/libpng/commit/8d1672537324d99c6e65eb78fc1678cdd46f7 5bd

	18 https://github.com/glennrp/libpng/commit/6c7459e455a4f7d95c7700e9326bb12396e6e b1f

	19 - Fix for handling empty first IDAT chunk from upstream:

	20 https://github.com/glennrp/libpng/commit/3f46c67c6989f480bd932428aa1705f6625db abf

	21 https://github.com/glennrp/libpng/commit/81f0273d54aa9de663253b197b3c8228d659c c36

OLD	NEW

« third_party/libpng/BUILD.gn ('K') | « third_party/libpng/README ('k') | third_party/libpng/arm/arm_init.c » ('j') | third_party/libpng/libpng.gyp » ('J')