Issues porting code to v2.1

Other misc things
Post Reply
Guesser
Member
Posts: 52
Joined: Mon Nov 21, 2011 2:00 pm

Issues porting code to v2.1

Post by Guesser »

I'm going through all my code making sure it still builds in v2.1 (last tested on a pre 2.0 nightly I think) and hitting a few bumps in the road.

First thing I can't solve is that

Code: Select all

defined(__SCCZ80)
now seems to be tripping when building with the default clib. I'm using the zx target and zx.cfg looks like this should only be set when -clib=new
User avatar
dom
Well known member
Posts: 2072
Joined: Sun Jul 15, 2007 10:01 pm

Re: Issues porting code to v2.1

Post by dom »

I don't think I have enough context, but __SCCZ80 looks like it has been defined since sometime in 2018 for both the preprocessor and the assembler.

It look like it's working correctly:

Code: Select all

int main() {
#if defined(__SCCZ80)
#error sccz80 defined
#else
#error not with sccz80
#endif
}

% zcc +test test.c
test.c: line 5: #error sccz80 defined

% zcc +test test.c -compiler=sdcc
test.c:7:2: error: #error not with sccz80
Guesser
Member
Posts: 52
Joined: Mon Nov 21, 2011 2:00 pm

Re: Issues porting code to v2.1

Post by Guesser »

I've got

Code: Select all

#if defined(__SDCC) || defined(__SCCZ80)
/* using the new clib */
ioctl(1, IOCTL_OTERM_PAUSE, 0); // do not pause when screen is full
#endif
and the first compile line my makefile runs is

Code: Select all

zcc +zx -vn -I../include/sccz80 -lndos -l../lib/sccz80/idemodcall test.c -o sccz80_oldclib/test.bin
which barfs on ioctl() being undefined.



Edit: oh, I just re-read your reply properly whoops. Yes it gets set when the compiler is sccz80, but it didn't used to when using the classic library. Perhaps that was a bug at the time and it should have been doing then?
User avatar
dom
Well known member
Posts: 2072
Joined: Sun Jul 15, 2007 10:01 pm

Re: Issues porting code to v2.1

Post by dom »

Ah right, now I understand.

Yes, it's quite possible it was never defined which would've been wrong.

I don't think there's anything that distinguishes between new/old lib at a compilation level. The feeling being that the non stdlib API is sufficiently different that it would be odd to mix the two together.

There's the header internal __SYS_COMPILER_H__ which should get defined after you include any system header in classic (there's bound to be some that don't of course, but stdio.h definitely does) - I'll add a testable macro to classic to make it a little less gnarly.
Guesser
Member
Posts: 52
Joined: Mon Nov 21, 2011 2:00 pm

Re: Issues porting code to v2.1

Post by Guesser »

Testing for the existence of the IOCTL_OTERM_PAUSE definition is working for now.
I realise it's a peculiar use case, the program just tests all different versions of a library which is why I've written it to build on four compiler/library targets. (Or attempted to haha. Trying to fix function pointers now)
Guesser
Member
Posts: 52
Joined: Mon Nov 21, 2011 2:00 pm

Re: Issues porting code to v2.1

Post by Guesser »

I'm getting there now with all the new lib versions apparently working correctly, but now I notice my library is getting compiled into bank 7 for sccz80 classic lib. I vaguely recall having this problem before and the solution for how to tell the linker to put it all in one binary being provided on WoS, but there's no chance of finding the post with the search facilities on that forum now
User avatar
dom
Well known member
Posts: 2072
Joined: Sun Jul 15, 2007 10:01 pm

Re: Issues porting code to v2.1

Post by dom »

Guesser wrote: Wed Feb 10, 2021 2:29 pm I'm getting there now with all the new lib versions apparently working correctly, but now I notice my library is getting compiled into bank 7 for sccz80 classic lib. I vaguely recall having this problem before and the solution for how to tell the linker to put it all in one binary being provided on WoS, but there's no chance of finding the post with the search facilities on that forum now
I'm guessing it's assembler code?

In which case you'll need a section directive in the assembler. code_clib, data_clib, bss_clib, rodata_clib are probably good ones to choose?
Guesser
Member
Posts: 52
Joined: Mon Nov 21, 2011 2:00 pm

Re: Issues porting code to v2.1

Post by Guesser »

dom wrote: Wed Feb 10, 2021 2:31 pm In which case you'll need a section directive in the assembler. code_clib, data_clib, bss_clib, rodata_clib are probably good ones to choose?
That's cured it :)

I had section directives already, but they were code_lib :lol:
Post Reply