Changelog:
2023-12-22: LWTOOLS 4.22. This version comes with a couple of useful
additions including being able to specify STDIN as the source file
using - and the ability to specify an offset and length for
includebin. Of some use might be the --no-warn=ifp1 flag to suppress
warnings about the use of ifp1. Finally, the default compile
optimization flag is reduced to -O2. It seems there are still
compilers that actually generate incorrect code under -O3.
2023-04-23: LWTOOLS 4.21. This version comes with a couple of
bugfixes related to building with certain Windows tools as well as
an undefined memory access problem. Updating is recommended.
2022-08-17: LWTOOLS 4.20. It is highly recommended that everyone
using an older version upgrade to this release. The big change is
a fix to avoid relying on undefined memory when deciding whether
to register a symbol using the data or code address. Also fix the
basic output target to keep linesbelow 249 characters, a fix for
numeric entry points in lwlink, and a couple other miscelaneous
fixes.
Changelog:
11.0.1:
Fixes for w32api/Cygwin
11.0.0:
Notable changes:
New libdloadhelper.a, like libdelayimp.a but using Windows 8 and later APIs.
Fix race condition when building lib32 and lib64 in parallel on Windows.
*recalloc now only available from msvcr90 and later, UCRT.
Redirect access() to __mingw_access() on UCRT wrt to X_OK problems.
New Hyper-V APIs.
SEH based setjmp on ARM if supported by compiler.
--enable-cfguard to enable Control Flow Guard in CRT, requires compiler support, clang only at this time.
Implement some of the stack protector functions/variables so -lssp is now optional when _FORTIFY_SOURCE or -fstack-protector-strong is used.
_FORTIFY_SOURCE=3 support added if __builtin_dynamic_object_size is supported by the compiler (gcc 12 or later).
genstubdll removed.
uchar_c16rtomb, uchar_c32rtomb, uchar_mbrtoc16 and uchar_mbrtoc32 removed for MSVCR*, UCRT only for now.
Updates to DX12 headers and much more from Wine.
Many other new win32 APIs.
Packaged for wip by Olaf Seibert and myself.
64tass is cross assembler targeting the 65xx series of micro processors.
Features:
- Open source portable C with minimal dependencies
- Familiar syntax to Omicron TASS and TASM
- Supports 6502, 65C02, R65C02, W65C02, 65CE02, 65816, DTV, 65EL02, 4510
- Arbitrary-precision integers and bit strings, double precision floating point
numbers
- Character and byte strings, array arithmetic
- Handles UTF-8, UTF-16 and 8 bit RAW encoded source files, Unicode character
strings
- Supports Unicode identifiers with compatibility normalization and optional
case insensitivity
- Built-in "linker" with section support
- Various memory models, binary targets and text output formats (also
Hex/S-record)
- Assembly and label listings available for debugging or exporting
- Conditional compilation, macros, structures, unions, scopes
This follows lang/gcc* already having it, but the new wrapper behaviour
appears to have resulted in new fallout from these packages
previously being overlooked.
While here, use FORTIFY_SUPPORTED in mingw-w64-gcc instead of
overriding the user's choice of a FORTIFY pkgsrc variable.
Almost all uses, if not all of them, are wrong, according to the
semantics of BUILD_DEPENDS (packages built for target available for
use _by_ tools at build-time) and TOOL_DEPEPNDS (packages built for
host available for use _as_ tools at build-time).
No change to BUILD_DEPENDS as used correctly inside buildlink3.
As proposed on tech-pkg:
https://mail-index.netbsd.org/tech-pkg/2023/06/03/msg027632.html
to result in an "non-existent label" error when testing for the existence
of a label that does not yet exist (which is the whole point of that
expression).
Bump PKGREVISION to 1.
This is distinct from the other z80-asm package. Why do we have it, then?
Because this Z80 assebler has some features that the z80-asm assembler
does not.
The default lib/ directory at least on NetBSD
is lib, not lib64. If you are on a system with
lib64/ please try finding the appropriate override
(--libdir?).
Some pkglint cleanup while here.