diff options
Diffstat (limited to 'third_party/yasm/README.pdfium')
| -rw-r--r-- | third_party/yasm/README.pdfium | 102 |
1 files changed, 43 insertions, 59 deletions
diff --git a/third_party/yasm/README.pdfium b/third_party/yasm/README.pdfium index 81b286f5c8..41da312adb 100644 --- a/third_party/yasm/README.pdfium +++ b/third_party/yasm/README.pdfium @@ -1,55 +1,54 @@ Name: yasm URL: http://www.tortall.net/projects/yasm/ -Version: 1.2.0 +Version: 1.3.0 License: 2-clause or 3-clause BSD licensed, with the exception of bitvect, which is triple-licensed under the Artistic license, GPL, and LGPL License File: source/patched-yasm/COPYING License Android Compatible: yes Security Critical: no -With these patches merged: -* https://github.com/yasm/yasm/commit/a2cbb10ee1b90b73647667ac849c74d65761d412 -* https://github.com/yasm/yasm/commit/01ab853e68ef8aeded716d6f5b34895200f66a51 -* https://github.com/yasm/yasm/commit/82fafa7b5619e702c8681c959ade0746498e3cbc -* https://github.com/yasm/yasm/commit/2bd66514b6b100887c19d8598da38347b3cff40e -* https://github.com/yasm/yasm/commit/ab19547382660d81e0b4a0232dccb38f44c52a36 -* https://github.com/yasm/yasm/commit/9728322335cba96500861ef766b1546d096e5600 -* CHROMIUM.diff: this patch makes yasm deterministic. +Source: http://www.tortall.net/projects/yasm/releases/yasm-1.3.0.tar.gz +SHA-512: 572d3b45568b10f58e48f1188c2d6bcbdd16429c8afaccc8c6d37859b45635e1 + 06885d679e41d0bee78c23822108c7ae75aa7475eed5ba58057e0a6fe1b68645 +With these patches applied: +* CHROMIUM.diff: Combined patch from Chromium. + See Chromium's third_party/yasm/README.chromium for details. -See also the yasm.gyp file for a description of the yasm build process. -Instructions for recreating the yasm.gyp file. - 1) Get a clean version of the yasm source tree. The clean tree can be found - at: +See also the BUILD.gn file for a description of the yasm build process. - src/third_party/yasm/source/yasm +Instructions for recreating the BUILD.gn file. + 1) Update yasm and re-apply the patches. - 2) Run configure on the pristine source from a different directory (eg., - /tmp/yasm_build). Running configure from another directory will keep - the source tree clean. + 2) Make a copy of source in a different directory (e.g., /tmp/yasm_build) and + run configure. Using another directory will keep the source tree clean. An + out-of-tree build does not appear to work reliably as of yasm 1.3.0. 3) Next, capture all the output from a build of yasm. We will use the build - log as a reference for making the yasm.gyp file. + log as a reference for BUILD.gn. make yasm > yasm_build_log 2> yasm_build_err 4) Check yasm_build_err to see if there are any anomalies beyond yasm's compiler warnings. - 5) Grab the generated Makefile, libyasm-stdint.h, config.h, and put into - the correct platform location. For android platform, copy the files - generated for linux, but make sure that ENABLE_NLS is not defined to - allow mac host compiles to work. For ios, copy the files from mac. + 5) Grab the generated libyasm-stdint.h and config.h and put into the correct + platform location. src/third_party/yasm/source/config/[platform] - While we do not directly use the "Makefile" to build, it is needed by - the "genmodule" subprogram as input for creating the available modules - list. + For android platform, copy the files generated for linux, but make sure + that ENABLE_NLS is not defined to allow mac host compiles to work. For + ios, copy the files from mac. For win, copy the libyasm-stdint.h from + linux and fix up config.h. - 6) Make sure all the subprograms are represented in yasm.gyp. + Find the YASM_MODULES line in the generated Makefile and update + src/third_party/yasm/source/config/Makefile. It is needed by the + "genmodule" subprogram as input for creating the available modules list. - grep '^gcc' yasm_build_log | + 6) Make sure all the subprograms are represented in BUILD.gn. + + grep -w gcc yasm_build_log | grep -v ' -DHAVE_CONFIG_H ' The yasm build creates a bunch of subprograms that in-turn generate @@ -57,26 +56,28 @@ Instructions for recreating the yasm.gyp file. subprogram do not have -DHAVE_CONFIG_H as a cflag. From this list, make sure all the subprograms that are build have - appropriate targets in the yasm.gyp. + appropriate targets in the BUILD.gn. You will notice, when you get to the next step, that there are some .c source files that are compiled both for yasm, and for genperf. - Those should go into the genperf_libs target so that they can be - shared by the genperf and yasm targets. Find those files by appending + Those should go into the yasm_utils target so that they can be shared by + the genperf and yasm targets. Find the files used by genperf by appending | grep 'gp-' - to the command above. + to the command above. Then grep for them without the 'gp-' prefix to see if + they are used in yasm as well. 7) Find all the source files used to build yasm proper. - grep -E '^gcc' yasm_build_log | + grep -w gcc yasm_build_log | grep ' -DHAVE_CONFIG_H ' | + sed -e 's/[&\\]*$//' | # Remove any trailing '&&'s and '\'s. awk '{print $NF }' | sed -e "s/'\.\/'\`//" | # Removes some garbage from the build line. sort -u | - sed -e "s/\(.*\)/'\1',/" # Add quotes to each line. + sed -e 's/\(.*\)/ "source\/patched-yasm\/\1",/' Reversing the -DHAVE_CONFIG_H filter from the command above should list the compile lines for yasm proper. @@ -84,9 +85,9 @@ Instructions for recreating the yasm.gyp file. This should get you close, but you will need to manually examine this list. However, some of the built products are still included in the command above. Generally, if the source file is in the root directory, - it's a generated file. + it's a generated file. Also remove the sources in the yasm_utils target. - Inspect the current yasm.gyp for a list of the subprograms and their + Inspect the current BUILD.gn for a list of the subprograms and their outputs. Update the sources list in the yasm target accordingly. Read step #9 @@ -95,48 +96,31 @@ Instructions for recreating the yasm.gyp file. 8) Update the actions for each of the subprograms. Here is the real fun. For each subprogram created, you will need to - update the actions and rules in yasm.gyp that invoke the subprogram to + update the actions and rules in BUILD.gn that invoke the subprogram to generate the files needed by the rest of the build. I don't have any good succinct instructions for this. Grep the build log for each subprogram invocation (eg., "./genversion"), look at - its command inputs and output, then verify our yasm.gyp does something + its command inputs and output, then verify our BUILD.gn does something similar. The good news is things likely only link or compile if this is done right so you'll know if there is a problem. - Again, refer to the existing yasm.gyp for a guide to how the generated + Again, refer to the existing BUILD.gn for a guide to how the generated files are used. Here are a few gotchas: 1) genmodule, by default, writes module.c into the current - directory. This does not play nicely with gyp. We patch the - source during build to allow specifying a specific output file. + directory. This does not play nicely with gn. We have a patch + to allow specifying a specific output file. 2) Most of the generated files, even though they are .c files, are #included by other files in the build. Make sure they end up - in a directory that is in the include path for the build. - One of <(shared_generated_dir) or <(generated_dir) should work. + in yasm_gen_include_dir. 3) Some of the genperf output is #included while others need to be compiled directly. That is why there are 2 different rules for .gperf files in two targets. - 9) Check for python scripts that are run. - - grep python yasm_build_log - - Yasm uses python scripts to generate the assembly code description - files in C++. Make sure to get these put into the gyp file properly as - well. An example is gen_x86_insn.py for x86 assembly. - - Note that at least the gen_x86_insn.py script suffers from the same - problem as genmacro in that it outputs to the current directory by - default. The yasm.gyp build patches this file before invoking it to - allow specifying an output directory. - - 10) Recreate the 'AdditionalOptions!': [ '/analyze' ] block so that VC++ - /analyze builds won't fail. - - 11) If all that's is finished, attempt to build....and cross your fingers. + 9) If all that's is finished, attempt to build....and cross your fingers. |