Pass CCexe=gcc to freetype make command #4
Comments
|
Passing Now it's failing at I'm trying to repro the build using recent emscripten getpass issue seems related to http://project.ktug.org/dvipdfmx/mailman/dvipdfmx/2011-February/000250.html |
|
There was also a suspicious |
|
To bypass the undefined functions, |
|
Then getting this: This is a false alert, since it happens before replacing icu binaries |
|
So it seems it's trying to use inline assembly duing non-native build and fails |
|
Also there's expected error |
This seems the only error that stays. And this makes sense, these numbers don't fit into UINT16 |
|
This issue was brought up in gentoo as well: https://bugs.gentoo.org/594660 |
|
Basically TECkit 2.5.3 is buggy with this respect and an update is needed. I'll first stub out these constants and then will try to bump the version |
|
Then it seems that passed fontconfig path is not propagated to xetex compilation: After patching this, it fails to find w2c/c-auto.h: |
|
Ah thanks for investigating! Sadly, this repository has bitrotted. The artifacts branch has some older compiled binaries from back when things worked. I'll try to take some time this weekend to take a look. |
|
I'm advancing towards building xetex + dvipdfm-x from scratch from recent TexLive repo: https://tex.stackexchange.com/questions/560046/how-to-build-xetex-and-dvipdfmx-from-source-texlive-2020 I currently have a proof of concept of in-browser-only tex editor (not new, was already tried by SwiftLatex and texlive.js and https://people.math.osu.edu/fowler.291/latex/ - I also try to hack around GitHub API for the usecase of editing CVs or small-ish repos with scientific papers): My frankenstein (Monaco + xterm.js + pdf.js + emscripten): Unfortunately I don't have experience with web programming, so all this is in one https://github.com/vadimkantorov/texet/blob/master/index.html (so that it's easily hackable). Unsolved issues: how to import TypeScript module in JavaScript (xterm.js Fit Addon); simple split-pane UI to resolve issues of pdf.js and xterm.js overlaying everything; xetex + bibtex + automatically downloading and caching texmf files in a worker thread (similar to your repo or https://github.com/manuels/texlive.js/) |
|
I managed to compile xetex and dvipdfm-x from TexLive (for now with native toolchain). However, creating a format file fails: |
|
Do you make use of native INSTALL_TL_UNX_ARCHIVE to get around this? |
|
It looks like in this case that's an error specific to the native texlive environment. It's looking for the |
|
You are right, I think (I don't have a native install except for installer used as part of Makefile). I tried the following (texlive.js version which is slightly simpler), but still fails (I'll try again!). I think I need to pass it some paths to my new native install. How does Is profile file only destined for the installer? TEXLIVE_BASE_URL=http://mirrors.ctan.org/macros/latex/base.zip
TEXLIVE_INSTALLER_URL=http://mirror.ctan.org/systems/texlive/tlnet/install-tl-unx.tar.gz
mkdir -p texlive
echo selected_scheme scheme-basic > texlive/profile.input
echo TEXDIR $PWD/texlive >> texlive/profile.input
echo TEXMFLOCAL $PWD/texlive/texmf-local >> texlive/profile.input
echo TEXMFSYSVAR $PWD/texlive/texmf-var >> texlive/profile.input
echo TEXMFSYSCONFIG $PWD/texlive/texmf-config >> texlive/profile.input
echo TEXMFVAR $PWD/home/texmf-var >> texlive/profile.input
wget $TEXLIVE_INSTALLER_URL
pushd texlive
tar xzvf ../install-tl-unx.tar.gz
./install-tl-*/install-tl -profile profile.input
rm -rf bin readme* tlpkg install* *.html texmf-dist/doc texmf-var/web2c
echo "Done! Please run 'make texlive.lst' now!"
popd
wget $TEXLIVE_BASE_URL
mkdir -p latex_format
pushd latex_format
unzip -o ../base.zip
pushd base
$XELATEX_EXE -ini -etex unpack.ins
$XELATEX_EXE -ini -etex latex.ltx |
vadimkantorov@DESKTOP-4UF8FID:/mnt/c/Users/user/blfstexlive/texlive$ ls
LICENSE.CTAN README install-tl-20200826 release-texlive.txt texmf-dist texmf-var texmfcnf.lua
LICENSE.TL README.usergroups profile.input texmf-config texmf-local texmf.cnf
vadimkantorov@DESKTOP-4UF8FID:/mnt/c/Users/user/blfstexlive/texlive$ find texmf-dist -name cm
texmf-dist/fonts/afm/public/amsfonts/cm
texmf-dist/fonts/map/dvips/cm
texmf-dist/fonts/pk/ljfour/public/cm
texmf-dist/fonts/source/public/cm
texmf-dist/fonts/tfm/public/cm
texmf-dist/fonts/type1/public/amsfonts/cmSo in theory fonts are present. How do I point newly built $XELATEX_EXE to the prepared |
|
I believe I think setting [1] https://wiki.archlinux.org/index.php/TeX_Live#texmf_trees_and_Kpathsea |
|
The full script I currently execute is here: https://gist.github.com/vadimkantorov/501634e4f0c93b2940b43aea071dff03 So yes, the primary problem seems to be in discovery of tools' paths. I'll try TEXMFDIST |
|
|
|
Here is strace of kpsewhich failing: |
|
Yay! There were some stupid path bug on my side. I managed to get a latex format file |
|
Complete script here: https://gist.github.com/vadimkantorov/501634e4f0c93b2940b43aea071dff03 |
|
Will now try your next steps after the format file is done |
|
Would you have an advice on how to share FS between several Emscripten MODULARIZE'd programs? emscripten-core/emscripten#12074 E.g. I first want to not deal with objects and have a common FS and manually launch xetex / bibtex (if needed) / dvipdfmx modules (for now without workers). For that it'd be good to have them a shared MEMFS. |
|
I see. I read through the issues referenced. What we really need is a pluggable filesystem or an abstraction to hack away on emscripten-core/emscripten/issues/777. Depending on the extent of the data, maybe a workaround is to just copy what you need among the modularized filesystems. The common shared files, like the tex distribution itself, would still be accessed lazily with XHR. This may mean more memory use, but the common requests should go to the browser cache, so maybe things would be just fine. |
Makes sense! At least until there is some feedback in emscripten repo! So will now try to build xetex/dvipdfmx with emscripten. Will let you know how it builds now from source (if the issues you described still persist) |
|
Do I understand correctly that your Makefile does not build a separate kpathsea binary? And somehow builds it into xetex itself? |
|
So emconfigure of TexLive (from trunk) succeeded. Somehow upmendex tries to check the compiler and doesn't detect the .js output (even if it's not required, TexLive still tries to configure everything and does it in making time!). Can't figure out a way to patch it out :( or set some config.site / config.cache presets. Would be glad if you have any advice! |
|
I managed to continue the build by removing upmendex from texlive-source/texlive-build-wasm/texk/Makefile from CONF_SUBDIRS variable, but definitely a cleaner hack would be great |
|
Not sure why it tries to search for xelatex.fmt when it is preloaded and texmf.cnf seems discovered ok |
|
Afte specifying format file explicitly, I started to get: So apparently there is some error, and no xdv is produced, but the output is scrambled :( |
|
I was running it with When I remove |
|
I think somehow it cannot create/open log file (judging from the stack trace), but not sure why it can't open it. |
|
This is very strange, because file reading clearly works. And writing files from JavaScript clearly works as well. |
|
After adding |
|
but it seems that logs should be created in the current directory ( |
|
Maybe it's a conflict between |
|
I removed |
|
I confirmed, openlogfile fails for some reason |
|
With very tedious printf debugging, I found out that for some reason xetex does not set the log file name (in |
|
It almost looks like constant string buffer got corrupted somehow |
|
Okay, I think I have found the reason, and it's really strange: zpackfilename (L13891 in attached Here is excerpt from native xetex0.c: And here's excerpt from wasm one: How these offsets are determined? Maybe I miss some compiler options? |
|
After copying xetex0.c from native (though still would be good to figure it out), things moved to "article.cls not found" - again some cnf/texmfdist problem. I've got |
|
After using texmf.cnf from |
|
How does fontconfig in your case discover fonts? Do you bundle the fonts somehow? |
|
Do you configure it somehow to look into |
|
FONTCONFIG_PATH and FONTCONFIG_FILE helped! |
|
When I did this some time ago, I recall setting |
|
Everything mostly worked! I managed to run XeTeX in browser (for now in synchronous mode) and even to link xetex and dvipdfmx in one executable by renaming some symbols |
|
nice! |
|
|
|
After renaming a few symbols and creating some dummy files, #include <string.h>
extern int busymain_xetex(int argc, char* argv[]);
extern int busymain_dvipdfmx(int argc, char* argv[]);
int main(int argc, char* argv[])
{
if(strcmp("xetex", argv[1]) == 0 || strcmp("xelatex", argv[1]) == 0)
return busymain_xetex(argc - 1, argv + 1);
else if(strcmp("dvipdfmx", argv[1]) == 0)
return busymain_dvipdfmx(argc - 1, argv + 1);
}calling this multiple times via I think of making some latexmk surrogate in C to simplify JavaScript interaction + this static "all-in-one" scheme would be useful for native builds as well |
Would you have any ideas about this? |
|
A problem with implementing |
|
I don't know what the state of support for system calls is today with emscripten, but perhaps it's worth a shot trying a wrapper with |
|
I managed to get bibtex8 working as well. Now it's a single executable combining xetex/bibtex8/dvidpfmx |
|
|
|
A question: all these three tools together (unoptimized) take 45 Mb of wasm. How far did you manage to go by enabling O3 + maybe lto? |
|
In my memory, |
This seems to remove the need for copying apinames from native build and maybe makes the native build less necessary
The text was updated successfully, but these errors were encountered: