Re: Unable to build MiKTeX

A wrote:
> Answering your question about the basic background for what I'm doing: My
> goal is to add a certain Lua library to LuaLaTeX.  The library has to be
> built from source, but when I build it with LuaRocks and try to use it in
> an existing MiKTeX installation, then the module's DLL doesn't work and is
> rejected by LuaLaTeX for some reason.  I'm hoping to either build MiKTeX
> statically with this Lua module to get it working, or perhaps make it so
> that MiKTeX and the library DLL are built with the same environment so
> that the DLL can be accepted.  I might ask for further assistance on this
> soon.
> Anyways...

One step at a time :o)

> It looks like my DLL errors with running "miktex-texworks.exe" might have
> been something transient because I needed to try different Qt versions
> earlier, needed to take additional steps to get Xsltproc working, and was
> trying to resume my build.  I "bit the bullet" and rebuilt everything from
> the beginning using the most recent setup that we found works with Qt
> version 5.8.0-beta (and after taking the needed steps to get Xsltproc
> working).  I got "nmake" and "nmake install" to complete successfully.
> The latter command installs to the folder "C:\miktex\build-install".  In
> order to get "miktex-texworks.exe" to work, I found that I first need to
> copy the following DLL files from "C:\Qt\Qt5.8.0\5.8\msvc2015_64\bin" to
> "C:\miktex\build-install\texmf\miktex\bin\x64" (the folder containing
> "miktex-texworks.exe" in the "nmake install" destination):
>   - Qt5Widgets.dll
>   - Qt5Gui.dll
>   - Qt5Core.dll
> After copying these DLL files, "miktex-texworks.exe" is able to run and
> the window comes up.  Note: Simply having
> "C:\Qt\Qt5.8.0\5.8\msvc2015_64\bin"
> in my PATH environment variable does not seem to suffice.  The program
> seems to need the DLL files to be present in the same folder with it.
> Please let me know if manually copying these DLL files this way is not the
> ideal method.

It surprises me that you *have* to copy it - is that even the case if you put the Qt PATH *first* in your PATH? However, this is how MiKTeX does it, so you're probably fine - in fact, at this stage, it's worth just comparing your installed directory with a tree created by MiKTeX's own installer. It's sadly normal on Windows to install all the libraries you need with each program - I guess disk space is cheap, but it's very dirty (I, for example, resent having multiple installation of Cygwin/MSYS arising from Git-for-Windows, etc. having to package it internally). 

> When you say to set the CMake build options, is the primary way to do this
> by editing the values in "C:\miktex\build\CMakeCache.txt" (which is
> generated by the CMake command and used as an input to NMake)?  Here's
> what happened when I edited the file to enable the options you mentioned
> and similar options, and then ran "nmake install" again afterward:
>   - Setting "INSTALL_MIKTEX_HEADERS", "INSTALL_STATIC_LIBRARIES", and
> "MIKTEX_SELF_CONTAINED" to "ON" (default was "OFF"): I think that the
> build process built some additional items, and I found that the resulting
> install target directory ("C:\miktex\build-install") has some more
> contents in the "include" and "lib" subdirectories.
>   - Setting "INSTALL_PACKAGE_DATABASE" to "ON" (default was "OFF"): The
> build process seems to want the "wget" program so that it can connect to
> the Internet and download packages.  (Based on information in the source
> file "C:\miktex\miktex-2.9-master\CMakeLists.txt", I believe that it wants
> to download from "ctan.org".)

I think the official way is -DINSTALL_PACKAGE_DATABASE=ON (possibly -DINSTALL_PACKAGE_DATABASE:BOOL=ON).

> I ran the Cygwin setup again and installed "wget" (version 1.18-1).  This
> makes Cygwin install the following dependencies: libgnutls28 version
> 3.3.17-1, libhogweed2 version 2.7.1-1, libidn11 version 1.29-1, libidn2_0
> version 0.11-1, libnettle4 version 2.7.1-1, libpsl5 version 0.14.0-2,
> libunistring2 version 0.9.6-1.  (An update for the Cygwin installer became
> available since the last time that I ran it, but I didn't install that
> update at this time.)
> 
> With "INSTALL_MIKTEX_HEADERS", "INSTALL_STATIC_LIBRARIES",
> "MIKTEX_SELF_CONTAINED", and "INSTALL_PACKAGE_DATABASE" all set to "ON" in
> "C:\miktex\build\CMakeCache.txt", I then deleted the "C:\miktex\build-
> install" directory and re-ran "nmake" in "C:\miktex\build".  I got the
> following errors at the beginning and the end:
> ---- Beginning of head of nmake output: ----
> 
> Microsoft (R) Program Maintenance Utility Version 14.00.24210.0 Copyright
> (C) Microsoft Corporation.  All rights reserved.
> 
> xz: (stdin): File format not recognized
> /usr/bin/tar: Child returned status 1
> /usr/bin/tar: Error is not recoverable: exiting now
> xz: (stdin): File format not recognized
> /usr/bin/tar: Child returned status 1
> /usr/bin/tar: Error is not recoverable: exiting now

Hmm, looking at it, I wonder if it's not actually downloading anything. What's the output from wget further up the log?

> -- Configuring done
> -- Generating done
> -- Build files have been written to: C:/miktex/build [  0%] Built target
> gen_test_char [  0%] Built target gen-apr-headers [  1%] Built target
> MiKTeX209-apr
> ---- End of head of nmake output. ----
> 
> ---- Beginning of tail of nmake output: ---- [100%] Built target miktex-
> luajit Install the project...
> -- Install configuration: "RelWithDebInfo"
> CMake Error at cmake_install.cmake:31 (file):
>   file INSTALL cannot find "C:/miktex/build/mpm.ini".
> 
> 
> NMAKE : fatal error U1077: 'echo' : return code '0x1'
> Stop.
> 
> ---- End of tail of nmake output. ----

This is predictable given the earlier failure.

> If I retry "nmake install", then the errors at beginning don't repeat, but
> the error at the end does repeat.
> 
> If I then change "INSTALL_PACKAGE_DATABASE" back to "OFF", then the
> build/install works as before.
> 
> What I'm actually wondering is: Can I generate the "Basic MiKTeX
> Installer"
> that contains the full MiKTeX installation without an immediate need to
> download anything external?  This is usually named "basic-miktex-
> <version>-x64.exe" when you download it from "
> https://miktex.org/download".  Currently I only see what seems to be the
> "MiKTeX Net Installer" being generated, which is the setup that requires a
> download of external packages; the file path is "C:\miktex\build-
> install\texmf\miktex\bin\x64\setup.exe" in my install target, and is named
> "setup-<version>-x64.exe" when you download it from "
> https://miktex.org/download".  Is a successful build with
> "INSTALL_PACKAGE_DATABASE" set to "ON" required in order to generate the
> "Basic MiKTeX Installer"?  You mentioned the packaging repo which I see at
> "
> https://github.com/MiKTeX/miktex-packaging".  Is that repo required to
> build the "Basic MiKTeX Installer"?

This is something I couldn't see from the main repository - I'm not sure if Christian is following this thread - it might be worth your starting a new one for how to (re-)create the standard installers.

It looks to me that the project for doing this is not included in the repo.

I would be surprised if you can generate the installer without needing to go online (at least not without editing or maintaining your own CTAN cache) - once you've compiled the MiKTeX binaries, the rest of the package repository is "just" repackaged from CTAN.

For what you're trying to do, it may be better to be trying to replace appropriate binaries in a pre-installed MiKTeX installation - once that's working, you could then look possibly at creating your own packages. But (personally) I'd try getting your DLL to work with your new build of lualatex before worrying about making the whole process neater. 


David


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Q: How can I leave the mailing list?
A: See http://docs.miktex.org/faq/support.html#leavingml