19 August 2018, 04:58 | #21 |
Registered User
Join Date: Aug 2018
Location: Minneapolis, USA
Posts: 301
|
I haven't had to muck around with code signing yet, but there are some promising looking links off that stack overflow page, thanks.
The great news is that Leffman's binaries 'just work'. ! Thanks ! I can compile and run. I suppose I'll have to find out how to fix the issue or I'll never be able to get an update, but for now, I'm able to create Amiga apps, and that's great. Thanks folks! |
21 August 2018, 15:29 | #22 | |
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,510
|
Quote:
The difference is that Leffmann's LLVM is much older. But what has changed between those versions? Of course, there could be a compiler bug, but it would be quite unlikely. |
|
05 November 2019, 15:51 | #23 |
Registered User
Join Date: Nov 2016
Location: Black Forest / Germany
Posts: 14
|
I guess I have a very similar problem with the ucpp part of vbcc.
I managed to compile vbccm68k and vbccppc on Windows using PellesC. A previous attempt with lcc-win32 failed because of missing/broken 64bit shift operations (in lcc-win32). PellesC successfully compiled vasm, vlink and vbcc to Win32 as well as Win64 binaries. I get an error 261 in line -1 : missing macro name. My command line simply is: vbccm68k test.c It starts in main.c with a call to define_macro(). The first macro is "__VBCC__" which is defined successfully. Then comes a macro that starts with "__entry=" and it fails. Every macro with a '=' in it fails with error 261. So I got to macro.c/define_macro(). There is this line: *(c + n - 1) = '\n'; This will overwrite the terminating 0 with a newline character, leaving the string without '\0' terminator. Either fix it by increasing variable 'n' or change sdup() to allocate one extra byte. I noticed this when I added some debug output. However, this potential bug is not the cause of the problem. macro.c/handle_define() generates the error when the next_token() loop doesn't find a name. So, a macro definition like "__M68000=1" is changed to "__M68000 1\n" before being parsed, but something goes wrong from there. |
05 November 2019, 22:01 | #24 | |
Registered User
Join Date: Dec 2016
Location: England
Posts: 87
|
Quote:
|
|
05 November 2019, 23:16 | #25 | |
Registered User
Join Date: Nov 2016
Location: Black Forest / Germany
Posts: 14
|
Quote:
Thank you. Yes, that works. Of course, I expected that. But the point is, vbcc should compile with almost any C compiler, it's meant to be easily portable. As the thread starter's case and mine have shown, there is something about vbcc that some compilers don't get right - and there must be a reason for that. For example, different compilers give different warnings. PellesC is pretty strict and gives dozens of warnings when compiling vbcc, and they're valid warnings about potentially uninitialized variables, comparing signed with unsigned numbers, unreachable code, unused data etc. Good code is unambiguous and there are no two ways to interpret it. I'm trying to find the ambiguity in vbcc's code. |
|
06 November 2019, 00:34 | #26 | |
Registered User
Join Date: Dec 2016
Location: England
Posts: 87
|
Quote:
|
|
06 November 2019, 03:06 | #27 |
Registered User
Join Date: Nov 2016
Location: Black Forest / Germany
Posts: 14
|
I compiled vbcc with Visual Studio 2019 Community Edition and it works. However it required some work because what is a warning in PellesC is considered an error in MSVC. It doesn't like potentially uninitialized variables at all. It also throws some warnings that might be interesting.
Now that I have a working build for comparison, I am trying to investigate what the problem is with the other compiler. I think it should be possible to compile an lcc-derivative with another lcc-derivative. I always prefer them over MSVC or GCC. |
07 November 2019, 22:12 | #28 | ||||||
Natteravn
Join Date: Nov 2009
Location: Herford / Germany
Posts: 2,510
|
Quote:
But in this case I guess the replacement is harmless, as the lexer-state structure gets the length of that string in 'ebuf' before handle_define() is called. It doesn't need a termination character. Quote:
Quote:
Quote:
Quote:
Quote:
|
||||||
Currently Active Users Viewing This Thread: 1 (0 members and 1 guests) | |
Thread Tools | |
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Need a little help getting started... | stevecole | New to Emulation or Amiga scene | 20 | 18 April 2009 21:30 |
Need help gettin started | guybhoy | New to Emulation or Amiga scene | 12 | 16 February 2008 06:09 |
Getting started!! | thequeenfan | New to Emulation or Amiga scene | 14 | 18 December 2003 23:46 |
Just getting started | scot_pete | New to Emulation or Amiga scene | 6 | 24 June 2002 19:14 |
Getting started again | The Shadow | New to Emulation or Amiga scene | 1 | 07 April 2002 22:42 |
|
|