Search found 4 matches
- Thu Feb 06, 2020 3:01 am
- Forum: Programming
- Topic: [solved] "Symbol already defined" error with ACME assembler
- Replies: 5
- Views: 1824
Re: "Symbol already defined" error with ACME assembler
Thanks for the welcome! No worries about not catching this, of course; I just wanted to make sure to follow up with the solution not to leave it dangling.
- Wed Feb 05, 2020 2:48 am
- Forum: Programming
- Topic: [solved] "Symbol already defined" error with ACME assembler
- Replies: 5
- Views: 1824
Re: "Symbol already defined" error with ACME assembler
Oh I think I get it. On pass 1, the "a" label is at $8000 and ."reset" is at 0x8006. However on pass 2, the "a" label is no longer defined, so it wants to put the "reset" label at $8000, which is redefining it to a different value.
I verified this by moving the !src to *after* the reset block, and ...
I verified this by moving the !src to *after* the reset block, and ...
- Wed Feb 05, 2020 2:17 am
- Forum: Programming
- Topic: [solved] "Symbol already defined" error with ACME assembler
- Replies: 5
- Views: 1824
Re: "Symbol already defined" error with ACME assembler
Here's the error I get:
Error - File test.a, line 8 (Zone <untitled>): Symbol already defined.
Line 8 refers to the "reset" label.
If I remove the !ifdef in lib.a, it works fine.
I notice that the libraries in https://github.com/meonwax/acme/tree/master/ACME_Lib seem to be entirely macros ...
Error - File test.a, line 8 (Zone <untitled>): Symbol already defined.
Line 8 refers to the "reset" label.
If I remove the !ifdef in lib.a, it works fine.
I notice that the libraries in https://github.com/meonwax/acme/tree/master/ACME_Lib seem to be entirely macros ...
- Tue Feb 04, 2020 11:52 am
- Forum: Programming
- Topic: [solved] "Symbol already defined" error with ACME assembler
- Replies: 5
- Views: 1824
[solved] "Symbol already defined" error with ACME assembler
I'm having trouble understanding why I'm getting a "Symbol already defined" error from acme. It seems to happen when I include a .a file that triggers a second assembler pass, but I'm not sure what to do to mitigate the problem. I managed to reproduce the problem with a couple small files ...