| Age | Commit message (Collapse) | Author | Lines |
|---|
|
OpenSSL can't automatically detect the architecture of Mac OS systems, so
as it suggests on its Wiki, it needs some help for doing that. With this
commit, we are checking the build on Mac OS with the presence of `otool'
(Mac OS's linker). If it's there, we'll add the OpenSSL configuration
options suggested by OpenSSL's Wiki.
|
|
Until now, we weren't including the `rpath' linking options to the basic
dependencies. They are now added. Also, when the download of an input file
fails for any reason, an empty file won't be replaced there any more.
|
|
We were missing a `\' at the end of the `$(call' function of Coreutils to
connect the two lines. It has been fixed now.
|
|
To enable easy downloading of HTTPS links with Wget (this pipeline's defaut
downloader), we need a set of trusted CA certificates. Until the time that
we can generate one ourselves, one generic set of trusted CA certificates
is now downloaded like a tarball and placed in the OpenSSL configuration
directory.
With these CA certificates, within the pipeline we can now safely use the
pipeline's own installed Wget.
|
|
Some high-level programs like Wget and cURL need to be built in shared mode
because they also include dynamic loading of libraries. Therefore, if we
only build the lower-level libraries in static mode, our own build will be
ignored and they will go and find the system's shared libraries to link
with. Because of this, for now, we have manually set the `static_build'
variable in the configure script to `no'.
Also, if the downloader fails, we'll delete the output (an empty file in
the case of Wget) because it interefers with a target definition.
|
|
The TeX Live installer needs Wget to operate smoothly, especially on recent
Mac OS systems that don't have Wget pre-installed. Also, it would be good
for the pipeline to have its own downloader. So with this commit, the
pipeline also installs Wget and OpenSSL which is a dependency.
Many other small changes/fixes were done in this process.
|
|
The main reason I wasn't using cURL as a downloading tool was that I wasn't
familar with how to ask it to follow a re-direct. But I just found out that
its with the `-L' configure time option. So it is now added as a downloader
tool to the pipeline.
|
|
GNU Binutils (which provides the GNU Linker) is not ported to Mac OS
systems. GCC also takes a very long time to build, and if we are to still
have linking problems with LLVM's linker, it would be better to just ignore
GCC also and use the system's C compiler and linker together.
So for the time being, GCC isn't a main target of the basic dependencies
and won't be installed. But we have kept the rules that were checked on a
GNU/Linux operating system.
|
|
The pipeline now installs GCC and all its necessary prerequisites.
|
|
The linker of LLVM version 10.0.0 (clang-1000.11.45.5) doesn't recognize
the `-rpath' linker option! After some searching, apparently it does
recognize `-rpath-link' so we are testing with that now.
|
|
Until now we weren't explicity writing the full path of the dynamic
libraries necessary for linking a program. But now with
`-Wl,-rpath=$(ildir)' we ensure that the linker keeps the address of the
dynamic libraries necessary for linking at linking time, not running
time. Also, `pkg-config' is also built when preparing the basics. Several
other minor corrections were made thanks to the great help of Raúl Infante
Sainz.
|
|
The high-level dependencies are now built without having access to the
system's PATH. To do this, all the necessary software that we aren't
building ourselves are now brought into the installed `bin/' directory
using a symbolic link to the corresponding software on the host. To do
this, it was also necessary to increase the number of basic/low-level
packages that we are building, and add several more (Diffutils and
Findutils).
With this process in place, we now have a list of the exact software
packages that we are not building our selves, enabling easy building of all
such dependencies in the future.
|
|
While working on a research project using this pipeline, I noticed that we
don't have any `sh' executable within our PATH. However, some programs
(including Gnuastro's configure script, when it is checking for shells to
use with Libtool) check and use it. So after building Bash, we also build
an `sh' symbolic link to point to the built Bash executable.
|
|
The system's libraries are no longer used in building the higher-level
dependencies. Also, thanks to Raul Infante Sainz, we found out that Bash's
build script was still removing the extra directory information (not
good!).
|
|
GNU Coreutils are basic programs that can help in the configuration of
higher-level programs. Because of that, it was a dependency of almost all
software built in `dependencies.mk'. To make things more clear, easier to
read and faster (when building in parallel), the building of Coreutils is
now moved to the `dependencies-basic.mk' rules. There, it is built
along-side Bash. Since `dependenceis-basic.mk' is run and completed before
`dependencies.mk', with this, we can be sure that Coreutils is present by
the time we want to build the higher-level programs.
Also, Zlib is now added as a dependency of Git also (it is necessary for
its build).
|
|
When the C compiler is not GNU GCC, linking with GNU Binutils is going to
cause problems. So until the time that we can include GCC into this
pipeline, its best to avoid Binutils also.
Also, for building CMake, we were relying on an installed CMake, but now,
we are using its own `./bootstrap' script, so it can be built even if the
host system doesn't have CMake.
Also, for TeX Live, we are now setting a custom file as main target to
avoid complications with symbolic links as targets in Make.
Finally, when the user says they don't want to re-write an existing
configuration file, no extra notices will be printed and the configure
script will immediately start building programs.
|
|
Until now, we were using a customized `tar.lz' tarball for Gzip. But on
systems that don't have GNU Tar, this will cause a problem (non-GNU Tar
doesn't recognize `.tar.lz'). So to keep things simple, we are using the
customized gzip in `tar.gz' format. After the internal build of GNU Tar and
Lzip, the default method of unpacking (`tar xf XXXXX.tar.XX') will work
nicely on all the standard compression algorithms and we don't have to
modify our commands based on the algorithm (nice feature of GNU Tar).
|
|
Since the final product of the pipeline is a LaTeX-created PDF file, it was
necessary to also have LaTeX within the pipeline. With this commit, TeX
Live is also built as part of the configuration and all the necessary
packages to build the PDF are also installed and mentioned in the paper
along with their versions.
|
|
The default Mac compiler has problems building static libraries. Since we
are not yet building the GNU C Compiler as part of the pipeline, we'll have
to rely on the host system's compiler. Therefore, a check is now added a
the start of the configure script that will build a minimal program with
the `-static' flag and if it fails, it will print a warning. Afterwards,
none of the dependencies will be built with the `-static' flag.
|
|
A semi-colon was missed in defining the link for `zlib'. It is now added.
|
|
To have better control over the build, GNU Binutils, Bzip2, GNU Gzip, and
XZ Utils have also been added to the pipeline. Some other minor cleanups
and fixes were also implemented throughout the process.
|
|
Until now, when a package was to be built statically, we were adding the
`--static' option to `CFLAGS'. This was the wrong place to put it! It
should be in the linking step (thus `LDFLAGS'). Also, based on Bash's
configure script, we are now using the more generic form of `-static'
(single dash, not double dash).
On the other hand, the `--disable-shared' option isn't available in many of
the packages and it is highly redundant with the `-static' option, so it
has been removed to avoid an extra warning in such packages.
|
|
To ensure the easy unpacking and building of the programs, Lzip and Tar are
now also build during the initial setup phase.
Some minor corrections were also applied to make things cleaner and
smoother.
|
|
Until now, we used semicolons in Make's Call function definitions to build
the programs with GNU build system or CMake. Therefore, if any step of the
process failed, the rest would be ignorant to it and pass. Now, we use `&&'
to separate the different processing steps. In this way, we can be sure
that if any of them fails (during configuration, or building for example),
the pipeline will also stop and not continue to the next command (in the
same recipe).
Since the two Make Call functions were identical in the two
`dependencies-basic.mk' and `dependencies.mk', they are now in one file to
be imported in both.
This bug was found by Raul Infante Sainz.
|
|
After a test by Raúl Infante Sainz, we found out that the configure script
and the Make script for Bash and Make are making too many assumptions on
more recent versions of both. As a result, it couldn't be built.
Therefore, the `configure' script was modified to not use more recent tools
like `readlink' (to find the absolute address of a relative one). It was
also re-organized to not have to read the configuration parameters from a
text file. The parameters are directly read from the command-line and are
written into the proper file afterwards. This removes the need to opening a
text editor by the user (which also caused problems on Raúl's system).
To fix the Make version issue, the building of Bash and Make are now done
in a new Makefile (`reproduce/src/make/dependencies-basic.mk'). This file
doesn't make many of the assumptions that were made in
`dependencies.mk'. So it should hopefully work on any version of Make.
To help in debugging, for now, the Makefile of configure, are asked to work
on one thread (the `-j' option is commented in the `configure'). But after
checks, we'll fix this.
|
