diff options
Diffstat (limited to 'third_party/yasm/README.pdfium')
| -rw-r--r-- | third_party/yasm/README.pdfium | 142 |
1 files changed, 142 insertions, 0 deletions
diff --git a/third_party/yasm/README.pdfium b/third_party/yasm/README.pdfium new file mode 100644 index 0000000000..81b286f5c8 --- /dev/null +++ b/third_party/yasm/README.pdfium @@ -0,0 +1,142 @@ +Name: yasm +URL: http://www.tortall.net/projects/yasm/ +Version: 1.2.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. + + +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: + + src/third_party/yasm/source/yasm + + 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. + + 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. + + 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. + + 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. + + 6) Make sure all the subprograms are represented in yasm.gyp. + + grep '^gcc' yasm_build_log | + grep -v ' -DHAVE_CONFIG_H ' + + The yasm build creates a bunch of subprograms that in-turn generate + more .c files in the build. Luckily the commands to generate the + 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. + + 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 + + | grep 'gp-' + + to the command above. + + 7) Find all the source files used to build yasm proper. + + grep -E '^gcc' yasm_build_log | + grep ' -DHAVE_CONFIG_H ' | + awk '{print $NF }' | + sed -e "s/'\.\/'\`//" | # Removes some garbage from the build line. + sort -u | + sed -e "s/\(.*\)/'\1',/" # Add quotes to each line. + + Reversing the -DHAVE_CONFIG_H filter from the command above should + list the compile lines for yasm proper. + + 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. + + Inspect the current yasm.gyp for a list of the subprograms and their + outputs. + + Update the sources list in the yasm target accordingly. Read step #9 + as well if you update the source list to avoid problems. + + 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 + 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 + 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 + 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. + + 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. + + 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. |