- they are mostly pointless in all major jurisdictions
- many big corporations and projects already don't use them
- saves us from pointless churn
- git keeps history for us
- the year range is kept in COPYING
checksrc is updated to allow non-year using copyright statements
Closes#10205
Update bare GNU Make `Makefile.m32` to:
- Move objects into a subdirectory.
- Add support for MS-DOS. Tested with DJGPP.
- Add support for Watt-32 (on MS-DOS).
- Add support for AmigaOS.
- Rename `Makefile.m32` to `Makefile.mk`
- Replace `ARCH` with `TRIPLET`.
- Build `tool_hugehelp.c` proper (when tools are available).
- Drop MS-DOS compatibility macro `USE_ZLIB` (replaced by `HAVE_LIBZ`)
- Add support for `ZLIB_LIBS` to override `-lz`.
- Omit object files when building examples.
- Default `CC` to `gcc` once again, for convenience. (Caveat: compiler
name `cc` cannot be set now.)
- Set `-DCURL_NO_OLDIES` for examples, like autotools does.
- Delete `makefile.dj` files. Notice the configuration details and
defaults are not retained with the new method.
- Delete `makefile.amiga` files. A successful build needs a few custom
options. We're also not retaining all build details from the existing
Amiga make files.
- Rename `Makefile.m32` to `Makefile.mk` to reflect that they are not
Windows/MinGW32-specific anymore.
- Add support for new `CFG` options: `-map`, `-debug`, `-trackmem`
- Set `-DNDEBUG` by default.
- Allow using `-DOS=...` in all `lib/config-*.h` headers, syncing this
with `config-win32.h`.
- Look for zlib parts in `ZLIB_PATH/include` and `ZLIB_PATH/lib`
instead of bare `ZLIB_PATH`.
Note that existing build configurations for MS-DOS and AmigaOS likely
become incompatible with this change.
Example AmigaOS configuration:
```
export CROSSPREFIX=/opt/amiga/bin/m68k-amigaos-
export CC=gcc
export CPPFLAGS='-DHAVE_PROTO_BSDSOCKET_H'
export CFLAGS='-mcrt=clib2'
export LDFLAGS="${CFLAGS}"
export LIBS='-lnet -lm'
make -C lib -f Makefile.mk
make -C src -f Makefile.mk
```
Example MS-DOS configuration:
```
export CROSSPREFIX=/opt/djgpp/bin/i586-pc-msdosdjgpp-
export WATT_PATH=/opt/djgpp/net/watt
export ZLIB_PATH=/opt/djgpp
export OPENSSL_PATH=/opt/djgpp
export OPENSSL_LIBS='-lssl -lcrypt'
export CFG=-zlib-ssl
make -C lib -f Makefile.mk
make -C src -f Makefile.mk
```
Closes#9764
`windres` is not always auto-detected by autotools when building for
Windows. When this happened, the build failed with a confusing error due
to the empty `RC` command:
```
/bin/bash ../libtool --tag=RC --mode=compile -I../include -DCURL_EMBED_MANIFEST -i curl.rc -o curl.o
[...]
Usage: /sandbox/curl/libtool [OPTION]... [MODE-ARG]...
Try 'libtool --help' for more information.
libtool: error: unrecognised option: '-I../include'
```
Improve this by verifying if `RC` is set, and fail with a clear error
otherwise.
Follow-up to 6de7322c03
Ref: https://curl.se/mail/lib-2022-10/0049.html
Reported-by: Thomas Glanzmann
Closes#9781
`./configure --enable-shared --disable-static` fails when trying to link
a shared `curl.exe`, due to `libtool` magically changing the output
filename of `windres` to one that it doesn't find when linking:
```
/bin/sh ../libtool --tag=RC --mode=compile windres -I../../curl/include -DCURL_EMBED_MANIFEST -i ../../curl/src/curl.rc -o curl.o
libtool: compile: windres -I../../curl/include -DCURL_EMBED_MANIFEST -i ../../curl/src/curl.rc -o .libs/curl.o
[...]
CCLD curl.exe
clang: error: no such file or directory: 'curl.o'
```
Let's resolve this by skipping `libtool` and calling `windres` directly
when building `src` (aka `curl.exe`). Leave `lib` unchanged, as it does
need the `libtool` magic. This solution is compatible with building
a static `curl.exe`.
This build scenario is not CI-tested.
While here, delete an obsolete comment about a permanent `libtool`
warning that we've resolved earlier.
Regression from 6de7322c03
Reported-by: Christoph Reiter
Fixes#9803Closes#9805
After this update autotools builds will compile and link `.rc` resources
to Windows executables. Bringing this feature on par with CMake and
Makefile.m32 builds. And also making it unnecessary to improvise these
steps manually, while monkey patching build files, e.g. [0].
You can customize the resource compiler via the `RC` envvar, and its
options via `RCFLAGS`.
This harmless warning may appear throughout the build, even though the
autotools manual documents [1] `RC` as a valid tag, and it fails when
omitting one:
`libtool: error: ignoring unknown tag RC`
[0] 535f19060d/curl-autotools.sh (L376-L382)
[1] https://www.gnu.org/software/libtool/manual/html_node/Tags.htmlCloses#9521
Add licensing and copyright information for all files in this repository. This
either happens in the file itself as a comment header or in the file
`.reuse/dep5`.
This commit also adds a Github workflow to check pull requests and adapts
copyright.pl to the changes.
Closes#8869
The support for compiling on Mac OS 9 hasn't been modified since 2001
and has no active maintainer or packager, so it's time to remove it as
it's incredibly unlikely to work. If a maintainer re-emerges it can be
resurrected from Git history.
Closes: #8836
Reviewed-by: Daniel Stenberg <daniel@haxx.se>
Move checksrc.pl, firefox-db2pem.sh and mk-ca-bundle.pl since they don't
particularly belong in lib/
Also created an EXTRA_DIST= in scripts/Makefile.am instead of specifying
those files in the root Makefile.am
Closes#8625
tool_listhelp.c is now a separate file with only the command line --help
output, exactly as generated by gen.pl. This makes it easier to generate
updates according to what's in the docs/cmdline-opts docs.
cd $srcroot/docs/cmdline-opts
./gen.pl listhelp *.d > $srcroot/src/tool_listhelp.c
With a configure build, this also works:
make -C src listhelp
Closes#7787
Warning: this will make existing curl command lines that use metalink to
stop working.
Reasons for removal:
1. We've found several security problems and issues involving the
metalink support in curl. The issues are not detailed here. When
working on those, it become apparent to the team that several of the
problems are due to the system design, metalink library API and what
the metalink RFC says. They are very hard to fix on the curl side
only.
2. The metalink usage with curl was only very briefly documented and was
not following the "normal" curl usage pattern in several ways, making
it surprising and non-intuitive which could lead to further security
issues.
3. The metalink library was last updated 6 years ago and wasn't so
active the years before that either. An unmaintained library means
there's a security problem waiting to happen. This is probably reason
enough.
4. Metalink requires an XML parsing library, which is complex code (even
the smaller alternatives) and to this day often gets security
updates.
5. Metalink is not a widely used curl feature. In the 2020 curl user
survey, only 1.4% of the responders said that they'd are using it. In
2021 that number was 1.2%. Searching the web also show very few
traces of it being used, even with other tools.
6. The torrent format and associated technology clearly won for
downloading large files from multiple sources in parallel.
Cloes #7176
... and remove it from the dist tarball. It has served its time, it
barely gets updated anymore and "everything curl" is now convering all
this document once tried to include, and does it more and better.
In the compressed scenario, this removes ~15K data from the binary,
which is 25% of the -M output.
It remains in the git repo for now for as long as the web site builds a
page using that as source. It renders poorly on the site (especially for
mobile users) so its not even good there.
Closes#3587
- replace tabs with spaces where possible
- remove line ending spaces
- remove double/triple newlines at EOF
- fix a non-UTF-8 character
- cleanup a few indentations/line continuations
in manual examples
Closes https://github.com/curl/curl/pull/3037
$< is only allowed in implicit rules in some non-GNU makes (e.g. BSD,
AIX) so avoid use elsewhere by referencing the dependent curl.1 file
directly instead. This is somewhat tricky because the file is supplied
in the packaged tar ball (but not in git) but must still be able to be
rebuilt when its dependencies change. The right thing must happen in
both tar ball and git source trees, as well as in both in-tree and
out-of-tree builds.
The man page taken from the release package is found in a different
location than if it's built from source. It must be referenced as $< in
the rule to get its correct location in the VPATH.
- Add unit test 1604 to test the sanitize_file_name function.
- Use -DCURL_STATICLIB when building libcurltool for unit testing.
- Better detection of reserved DOS device names.
- New flags to modify sanitize behavior:
SANITIZE_ALLOW_COLONS: Allow colons
SANITIZE_ALLOW_PATH: Allow path separators and colons
SANITIZE_ALLOW_RESERVED: Allow reserved device names
SANITIZE_ALLOW_TRUNCATE: Allow truncating a long filename
- Restore sanitization of banned characters from user-specified outfile.
Prior to this commit sanitization of a user-specified outfile was
temporarily disabled in 2b6dadc because there was no way to allow path
separators and colons through while replacing other banned characters.
Now in such a case we call the sanitize function with
SANITIZE_ALLOW_PATH which allows path separators and colons to pass
through.
Closes https://github.com/curl/curl/issues/624
Reported-by: Octavio Schroeder
This allows the root Makefile.am to include the Makefile.inc without
causing automake to warn on it (variables named *_SOURCES are
magic). curl_SOURCES is then instead assigned properly in
src/Makefile.am only.
Closes#577
This fixes a build failure where openssl and libmetalink are used
together and the system linker does not do implicit linking (e.g.
Fedora 13 and later releases). The MD5 functions required for
metalink support must be pulled in from the openssl crypto library.
This is similar to commit c6e7cbb94e,
which fixes the same sort of problem for NSS builds.
This prevents targets like tool_hugehelp.c from leaving around
half-constructed files if the rule fails with GNU make.
Reported-by: Rafaël Carré <funman@videolan.org>
