since the "empty prefix means run from current dir" hack was removed,
cl65 --print-target-path no longer prints the path relative to the
binary, but the hardcoded library path which points to prefix, because
the code adds the hardcoded path first to the pathsearch, but then actually
only returns the first entry rather than looking whether the path exists.
closes#1754
GetProgPath() now resolves the path derived from argv[0] always
via realpath(3p) to its real location in the filesystem, and returns
the path including binary name, effectively making it work like
windows' GetModuleFileName(), so we can re-use the existing code
to strip the trailing binary name.
since symlinks are now always resolved, we no longer need the
special case code for linux to use /proc/self/exe for this purpose.
there was some concern that this will break windows' way of doing
file lookups relatively from the binary, rather than via hardcoded
locations, but so far each occurence adding e.g. "CA65_INC" to
the pathsearch is already shielded with an #ifndef _WIN32.
addressing #1726
until now, the strings intended to be hardcoded into the binary,
such as directory names and build id, were passed unquoted, which
means they're interpreted by the preprocessor as C tokens, rather
than strings, which can result in all sorts of "interesting"
behaviour such as interpreting paths starting with // as C++-style
comment.
this was then worked around using a stringize macro which turned
the tokens into a string (if they happened to be in a compatible
format).
adresses #1726
it's often required to see the full commandline when things go wrong.
the standard way for Makefile-only based buildsystems and autoconf
is to pass V=1 to make.
src/common/inttypes.h is a shim to fix building cc65 on
non-C99-compliant compilers missing inttypes.h (like VS2012 and
earlier). The shim is actually incomplete and does not define the PRI...
macros supplied by the actual compiler headers. Since we're planning to
use those macros, delete this header so cc65's source files instead use
host-supplied inttypes.h containing macro definitions.
There are many occurrences of unsigned long in codegen.h's function
arguments. Changing g_getimmed and g_defdata makes `make` succeed
without segfaulting. I don't know if it makes cc65 behave correctly in
all cases, or if there are more unsigned long that need to be changed.
The actor directives (.constructor, .destructor, .interruptor, and .condes)
can't handle a symbol that's already exported.
The relevant code does the checks in the wrong order.
For example, the following correct snippet does not assemble:
.export C
C: .constructor C, 5
The assembler outputs: test.s:2: Error: Address size mismatch for symbol 'C'
Exchanging both lines makes it work.
This fixes#1647; the patch is provided by 'kugelfuhr' and taken from there.
A missing factor in an expression causes an expected but missing token
to be skipped, leading to invalid flagged errors in the following line:
l = 3 +
lda #$00
An error should be output for line 1, but not for line 2. Actually, both
are flagged as errors:
test.s(1): Error: Syntax error
test.s(2): Error: Unexpected trailing garbage characters
This patch (as proposed in issue #1634 by kugelfuhr) fixes this.
