You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
127 lines
5.2 KiB
127 lines
5.2 KiB
Name: yasm
|
|
URL: http://www.tortall.net/projects/yasm/
|
|
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
|
|
|
|
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 BUILD.gn file for a description of the yasm build process.
|
|
|
|
Instructions for recreating the BUILD.gn file.
|
|
1) Update yasm and re-apply the patches.
|
|
|
|
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 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 libyasm-stdint.h and config.h and put into the correct
|
|
platform location.
|
|
|
|
src/third_party/yasm/source/config/[platform]
|
|
|
|
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.
|
|
|
|
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.
|
|
|
|
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
|
|
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 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 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. 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 -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/\(.*\)/ "source\/patched-yasm\/\1",/'
|
|
|
|
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. Also remove the sources in the yasm_utils target.
|
|
|
|
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
|
|
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 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 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 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 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 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) If all that's is finished, attempt to build....and cross your fingers.
|