English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Language > Coders. C/C++

 
 
Thread Tools
Old 16 December 2018, 14:12   #961
boemann
Registered User

 
Join Date: Dec 2018
Location: Copenhagen, Denmark
Posts: 3
I'm curious. Will it be possibly to run the compiler etc on the Amiga itself if I were to try and compile it.
You see, I'd prefer to do my program building on the Amiga too.
boemann is offline  
Old 18 December 2018, 13:29   #962
_dante_
Registered User

 
Join Date: Feb 2018
Location: Poland
Posts: 8
I have a problem using the toolchain on macOS Sierra 10.12.6.

First, I tried to use the precompiled, hosted build available at https://franke.ms/download/amiga-gcc-macos.tgz

Everything seemed to work until I wanted to compile sample program with libnix using -noixemul switch which results in the following error:
Code:
$ m68k-amigaos-gcc hello.c -noixemul -o hello
/opt/amiga/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/bin/ld: /opt/amiga/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/lib/libstubs.a(__UtilityBase.o):__UtilityBase.o:(.data+0x4): undefined reference to `__utilityname'
collect2: error: ld returned 1 exit status
Searching libstubs.a for '__utilityname'
Code:
m68k-amigaos-nm /opt/amiga/m68k-amigaos/lib/libstubs.a | less
I found only
Code:
__UtilityBase.o:
00000000 D ___LIB_LIST__
00000000 D ___UtilityBase
         U ___utilityname
without the
Code:
...
utility.o:
00000000 D ___utilityname
...
I found in the thread that it could be related to corrupted libnix build (but it's sad if the hosted version also suffer from that) thus I decided to compile the toolchain from sources.

I installed required packages using 'brew' including bash and gawk (as it was suggested in the thread to better use gnu awk than apple's awk because the second one is producing wrong header files) - in fact I tried both scenarios with gawk and apple's awk with no success.

Having all set up I did the steps according the instruction:
Code:
git clone https://github.com/bebbo/amiga-gcc
cd amiga-gcc
make update SHELL=/usr/local/bin/bash
make clean SHELL=/usr/local/bin/bash
make clean-prefix SHELL=/usr/local/bin/bash
make all SHELL=/usr/local/bin/bash
It goes well until it is building libnix, where the compilation is terminated with the following errors (full build log in the attachments):
Code:
m68k-amigaos-gcc -I/Users/Dante/Amiga/amiga-gcc/projects/libnix/sources/nix13/../headers -Os -fomit-frame-pointer -noixemul -mcrt=nix13 -S /Users/Dante/Amiga/amiga-gcc/projects/libnix/sources/nix13/extra/__oslibversion.c -o extra/__oslibversion.S 2>&1|tee extra/__oslibversion.err
m68k-amigaos-gcc -E -traditional -D_DOSBase=___DOSBase -D_UtilityBase=___UtilityBase -D_MathIeeeSingBasBase=___MathIeeeSingBasBase -D_MathIeeeSingTransBase=___MathIeeeSingTransBase -D_MathIeeeDoubBasBase=___MathIeeeDoubBasBase -D_MathIeeeDoubTransBase=___MathIeeeDoubTransBase -D_LocaleBase=___LocaleBase extra/__oslibversion.S -o extra/__oslibversion__2.S
m68k-amigaos-gcc -I/Users/Dante/Amiga/amiga-gcc/projects/libnix/sources/nix13/../headers -Os -fomit-frame-pointer -noixemul -mcrt=nix13 extra/__oslibversion__2.S -c -o extra/__oslibversion.o
rm extra/__oslibversion.S extra/__oslibversion__2.S
if test ! -s extra/__oslibversion.err; then rm extra/__oslibversion.err; fi
m68k-amigaos-gcc -I/Users/Dante/Amiga/amiga-gcc/projects/libnix/sources/nix13/../headers -Os -fomit-frame-pointer -noixemul -mcrt=nix13 -S /Users/Dante/Amiga/amiga-gcc/projects/libnix/sources/nix13/extra/allocvec.c -o extra/allocvec.S 2>&1|tee extra/allocvec.err
In file included from /opt/amiga/m68k-amigaos/ndk-include/inline/exec.h:16:0,
                 from /Users/Dante/Amiga/amiga-gcc/projects/libnix/sources/nix13/extra/allocvec.c:2:
/Users/Dante/Amiga/amiga-gcc/projects/libnix/sources/nix13/extra/allocvec.c:6:8: error: expected identifier or '(' before '{' token
 void * AllocVec(unsigned size, unsigned flags) {
        ^
/Users/Dante/Amiga/amiga-gcc/projects/libnix/sources/nix13/extra/allocvec.c:13:6: error: expected identifier or '(' before '{' token
 void FreeVec(unsigned * ptr) {
      ^
m68k-amigaos-gcc -E -traditional -D_DOSBase=___DOSBase -D_UtilityBase=___UtilityBase -D_MathIeeeSingBasBase=___MathIeeeSingBasBase -D_MathIeeeSingTransBase=___MathIeeeSingTransBase -D_MathIeeeDoubBasBase=___MathIeeeDoubBasBase -D_MathIeeeDoubTransBase=___MathIeeeDoubTransBase -D_LocaleBase=___LocaleBase extra/allocvec.S -o extra/allocvec__2.S
m68k-amigaos-gcc: error: extra/allocvec.S: No such file or directory
m68k-amigaos-gcc: fatal error: no input files
compilation terminated.
As I have written, I tried different scenarios using default apple's awk or gnu's awk. Tried also building with explicitly set clang compiler
Code:
CC=clang CXX=clang++ make all SHELL=/usr/local/bin/bash
All these efforts without success.

What I have missed or what I'm doing wrong?

Any help highly appreciated...
Thanks!
Attached Files
File Type: txt build-log.txt (22.4 KB, 16 views)
_dante_ is online now  
Old 18 December 2018, 14:06   #963
Hedeon
PPC Hacker

 
Join Date: Mar 2012
Location: Leiden / The Netherlands
Posts: 1,040
Normally, utilityname = utility.library. Not sure why it is not defined.

And nix13 is for AOS1.3 i think. I believe the file will add a custom AllocVec/FreeVec as those do not exist in 1.3. Maybe you are using 3.x includes to compile 1.3 stuff?

Just guessing here.
Hedeon is offline  
Old 18 December 2018, 17:33   #964
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 44
Posts: 1,281
Send a message via Yahoo to Samurai_Crow
Utility.library was introduced in Kickstart 2. It should not be defined in 1.3.
Samurai_Crow is offline  
Old 18 December 2018, 18:29   #965
_dante_
Registered User

 
Join Date: Feb 2018
Location: Poland
Posts: 8
Regarding 'utilityname' during sample code compilation:

Based on crt libraries supported I assume that compiling sample program for AOS1.3 requires additional switch -mcrt=nix13 to use libnix comapatible with AOS1.3.

I never used that switch (only -noixemul), so I think the default libnix is nix20 which should have __utilityname defined.

Regarding building libnix itself during toolchain compilation:
My basic understanding of the toolchain makefile is that ndk13 is 'emulated' based on ndk39. So it shouldn't be an issue building nix13/extra/allocvec.c containing emulated AllocVec/FreeVec routines which are based on ndk39 declarations that are included from /opt/amiga/m68k-amigaos/ndk-include/inline/exec.h. But the problem I can think of is that /opt/amiga/m68k-amigaos/ndk-include/inline/exec.h contains only preprocessor #defines and not declarations for AllocVec/FreeVec so their definition in the nix13/extra/allocvec.c is somehow incorrect to the compiler.

I wonder if it is related only to the toolchain compilation under macOS or Windows guys have similar issues?
_dante_ is online now  
Old 18 December 2018, 18:47   #966
alkis
Registered User

 
Join Date: Dec 2010
Location: Athens/Greece
Age: 48
Posts: 491
Quote:
Originally Posted by _dante_ View Post
Code:
$ m68k-amigaos-gcc hello.c -noixemul -o hello
/opt/amiga/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/bin/ld: /opt/amiga/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/lib/libstubs.a(__UtilityBase.o):__UtilityBase.o:(.data+0x4): undefined reference to `__utilityname'
collect2: error: ld returned 1 exit status
Can you provide a small source code (hello.c?) that illustrates the problem? We can then try to compile it and see if that's something in your end or in the toolchain.
alkis is offline  
Old 18 December 2018, 19:05   #967
_dante_
Registered User

 
Join Date: Feb 2018
Location: Poland
Posts: 8
Sure!

Source of hello.c is in fact Bebbo's 'simple C file to test' from https://franke.ms/amiga/gcc.wiki and it contains the following code:
Code:
#include <stdio.h>

int main(int argc, char **argv) {
        puts("hello world!");
        printf("argc=%ld\r\n", argc);
        for (int i = 0; i < argc; ++i) {
                printf("arg=%s\r\n", argv[i]);
        }
        return 0;
}

Last edited by _dante_; 18 December 2018 at 19:38.
_dante_ is online now  
Old 18 December 2018, 21:43   #968
alkis
Registered User

 
Join Date: Dec 2010
Location: Athens/Greece
Age: 48
Posts: 491
There is something wrong at your end.

Code:
m68k-amigaos-gcc hello.c -noixemul -o hello
alex[0]@omen eab$ ls -ltr hello
-rwxrwxr-x 1 alex alex 10568 ???  18 22:41 hello
Everything compiles fine here, on linux host.
alkis is offline  
Old 18 December 2018, 22:35   #969
Leffmann
 
Join Date: Jul 2008
Location: Sweden
Posts: 2,265
Quote:
Originally Posted by _dante_ View Post
I wonder if it is related only to the toolchain compilation under macOS or Windows guys have similar issues?

I can't build the toolchain for macOS, but on Windows Subsystem for Linux Ubuntu both the toolchain and that test program builds fine.
Leffmann is offline  
Old 20 December 2018, 11:32   #970
bebbo
botcher

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 389
Quote:
Originally Posted by _dante_ View Post
I have a problem using the toolchain on macOS Sierra 10.12.6.

First, I tried to use the precompiled, hosted build available at https://franke.ms/download/amiga-gcc-macos.tgz

...
I uploaded a recent version.

Also building the toolchain on that crappy wanker operating system is working again.
bebbo is offline  
Old 21 December 2018, 01:39   #971
_dante_
Registered User

 
Join Date: Feb 2018
Location: Poland
Posts: 8
Hi Bebbo!

The toolchain builds fine now under macOS but still only the 'newlib' crt is usable

It means that only build using the command below results in properly built executable:
Code:
m68k-amigaos-gcc hello.c -o hello-newlib
Building with 'libnix' crt still doesn't work at all, but the error is different as now it doesn't even progress to the linking phase:
Code:
m68k-amigaos-gcc hello.c -noixemul -o hello-noixemul
... or equivalent command (if I understood correctly)...
Code:
m68k-amigaos-gcc hello.c -mcrt=nix20 -o hello-nix20
... or AOS 1.3 compatible ...
Code:
m68k-amigaos-gcc hello.c -mcrt=nix13 -o hello-nix13
results in compilation errors related to unknown type name '__FILE':
Code:
In file included from /opt/amiga/m68k-amigaos/sys-include/stdio.h:60:0,
                 from hello.c:1:
/opt/amiga/m68k-amigaos/sys-include/sys/reent.h:304:3: error: unknown type name '__FILE'
   __FILE *_iobs;
   ^~~~~~
/opt/amiga/m68k-amigaos/sys-include/sys/reent.h:390:3: error: unknown type name '__FILE'
   __FILE *_stdin, *_stdout, *_stderr; /* XXX */
   ^~~~~~
/opt/amiga/m68k-amigaos/sys-include/sys/reent.h:425:3: error: unknown type name '__FILE'
   __FILE *__sf;           /* file descriptors */
   ^~~~~~
In file included from hello.c:1:0:
/opt/amiga/m68k-amigaos/sys-include/stdio.h:66:9: error: unknown type name '__FILE'
 typedef __FILE FILE;
         ^~~~~~
In file included from hello.c:1:0:
/opt/amiga/m68k-amigaos/sys-include/stdio.h: In function '__sputc_r':
/opt/amiga/m68k-amigaos/sys-include/stdio.h:692:10: error: request for member '_w' in something not a structure or union
  if (--_p->_w >= 0 || (_p->_w >= _p->_lbfsize && (char)_c != '\n'))
          ^~
/opt/amiga/m68k-amigaos/sys-include/stdio.h:692:26: error: request for member '_w' in something not a structure or union
  if (--_p->_w >= 0 || (_p->_w >= _p->_lbfsize && (char)_c != '\n'))
                          ^~
/opt/amiga/m68k-amigaos/sys-include/stdio.h:692:36: error: request for member '_lbfsize' in something not a structure or union
  if (--_p->_w >= 0 || (_p->_w >= _p->_lbfsize && (char)_c != '\n'))
                                    ^~
/opt/amiga/m68k-amigaos/sys-include/stdio.h:693:14: error: request for member '_p' in something not a structure or union
   return (*_p->_p++ = _c);
              ^~
/opt/amiga/m68k-amigaos/sys-include/stdio.h: In function '_getchar_unlocked':
/opt/amiga/m68k-amigaos/sys-include/stdio.h:747:10: error: request for member '_r' in something not a structure or union
  return (__sgetc_r(_ptr, _stdin_r(_ptr)));
          ^
/opt/amiga/m68k-amigaos/sys-include/stdio.h:747:10: error: request for member '_p' in something not a structure or union
  return (__sgetc_r(_ptr, _stdin_r(_ptr)));
          ^
Building with 'clib2' crt also fails but this time during the linking stage:
Code:
$ m68k-amigaos-gcc hello.c -mcrt=clib2 -o hello-clib2
/opt/amiga/lib/gcc/m68k-amigaos/6.4.1b/../../../../m68k-amigaos/bin/ld: cannot find ncrt0.o: No such file or directory
collect2: error: ld returned 1 exit status
I don't know if it could help somehow but I did manage to achieve the same results (with the same compilation errors) using previous toolchain code (without yours today's commits) when I excluded building of nix13 directory in "projects/libnix/sources/Makefile.in" or when I commented out the #include <inline/exec.h> in "projects/libnix/sources/nix13/extra/allocvec.c". I see that your solution for the 'libnix' compilation problem is by undefining AllocVec and FreeVec macros as they were caused errors during compilation of "projects/libnix/sources/nix13/extra/allocvec.c". It's of course better solution but similar result with errors mentioned above. I wonder though why compiling on Ubuntu doesn't produce the same errors - why GCC doesn't see these macros defined?

In the meantime I tried to build hello.c with all these crts under Ubuntu and it works great in each case.

Your support is invaluable so I would really appreciate 'libnix' and 'clib2' crts usable with your toolchain also on macOS
_dante_ is online now  
Old 21 December 2018, 11:04   #972
bebbo
botcher

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 389
Quote:
Originally Posted by _dante_ View Post
Hi Bebbo!

The toolchain builds fine now under macOS but still only the 'newlib' crt is usable

**removed some lines **

In the meantime I tried to build hello.c with all these crts under Ubuntu and it works great in each case.

Your support is invaluable so I would really appreciate 'libnix' and 'clib2' crts usable with your toolchain also on macOS
It comes down that
Code:
  readlink("/proc/self/exe", buf, 1023);
does not yield the executable path. And thus computing the libnix include folders failes. This might also affect other include path calculations and causes that ndk13-includes are not resolved too - that's why the macros for AllocVec/FreeVec are picked up...

I tried different approaches to get the executable path including
_NSGetExecutablePath,
proc_pidpath, ...
and nothing seems to work. (Maybe this increases your tolerance of my judgement for this os).

And no - I do not rollback to the static compiled prefix path.^

EDITH: I got _NSGetExecutablePath working.

but building libnix:
Code:
awk: ... makes too many open files
OMGWTF

I finally updated https://franke.ms/download/amiga-gcc-macos.tgz

Last edited by bebbo; 21 December 2018 at 22:55.
bebbo is offline  
Old 27 December 2018, 09:19   #973
cdh
Registered User

 
Join Date: Dec 2017
Location: Los Altos, CA, USA
Posts: 6
Problem with clib2 accept() and FS-UAE bsdsocket.library

Thank you Bebbo such an incredible cross-compiling toolchain! Your work is helping to enable a new generation of code for our classic Amiga computers.

Using your compiler, I've started porting an app (current OpenSSH) to the 68k Amiga which requires TCP sockets. I'm having some minor difficulty that probably someone more familiar with the 68k ABI and assembly can help with.

My development environment is Fedora 28, with The Bebbo gcc version I pulled and built from git:
    gcc version 6.4.1b 20181213-223951 (GCC)

My test environment is currently FS-UAE 2.9.7DEV5 with the UAE bsdsocket.library.
I'm compiling with flags
-Os -mcrt=clib2 -m68020-60 -lnet
among others.

The high level symptom I'm having is that a call to accept() on an established socket fails with a return code of -1, but errno = 0. This occurs just as the remote host attempts a connect. The remote host remains connected (to FS-UAE) even though the accept() returns -1.

I've investigated on the FS-UAE code and as far as I can tell, it is correctly inserting an fd number in register d0 before returning.

The relevant code in
projects/clib2/library/socket_accept.c
is as follows:
Code:
        new_socket_fd = __accept(socket_fd,cliaddr,(LONG *)addrlen);
        PROFILE_ON();

        if(new_socket_fd < 0)
        {
                SHOWMSG("could not accept connection");
                goto out;
        }
Using gdb to disassemble the above, I see:
Code:
   0x0007b4cc <+20>:    movea.l 0x18fc <main+1104>,a6
   0x0007b4d2 <+26>:    movea.l d0,a0
   0x0007b4d4 <+28>:    move.l 16(a0),d0
   0x0007b4d8 <+32>:    movea.l 20(sp),a0
   0x0007b4dc <+36>:    movea.l 24(sp),a1
   0x0007b4e0 <+40>:    jsr -48(a6)
   0x0007b4e4 <+44>:    blt.s 0x7b534 <accept+124>
   0x0007b4e6 <+46>:    jsr 0x85610 <__find_vacant_fd_entry>
Here's where I'm a little beyond my depth. To me, the above looks to be in error because it's not doing a
tst.l d0
before the
blt.s
instruction.

If I make a minor addition to the accept() library code:
Code:
        new_socket_fd = __accept(socket_fd,cliaddr,(LONG *)addrlen);
        PROFILE_ON();
        __asm("");

        if(new_socket_fd < 0)
        {
                SHOWMSG("could not accept connection");
                goto out;
        }
then the accept() call works as expected, and returns a valid fd to my calling program. Disassembly of accept() looks "better" to my untrained eyes as well:
Code:
   0x0007b4cc <+20>:	movea.l 0x18fc <main+1104>,a6
   0x0007b4d2 <+26>:	movea.l d0,a0
   0x0007b4d4 <+28>:	move.l 16(a0),d0
   0x0007b4d8 <+32>:	movea.l 20(sp),a0
   0x0007b4dc <+36>:	movea.l 24(sp),a1
   0x0007b4e0 <+40>:	jsr -48(a6)
   0x0007b4e4 <+44>:	move.l d0,d3
   0x0007b4e6 <+46>:	tst.l d0
   0x0007b4e8 <+48>:	blt.s 0x7b538 <accept+128>
   0x0007b4ea <+50>:	jsr 0x85634 <__find_vacant_fd_entry>
Where the compiler now saves d0 in d3 (??), and then does the
tst
that I would have expected.

Is there something wrong with the inline assembler of __accept()?
Code:
#define __accept(sock, addr, addrlen) ({ \
  LONG _accept_sock = (sock); \
  struct sockaddr * _accept_addr = (addr); \
  LONG * _accept_addrlen = (addrlen); \
  LONG _accept__re = \
  ({ \
  register struct Library * const __accept__bn __asm("a6") = (struct Library *) (__SocketBase);\
  register LONG __accept__re __asm("d0"); \
  register LONG __accept_sock __asm("d0") = (_accept_sock); \
  register struct sockaddr * __accept_addr __asm("a0") = (_accept_addr); \
  register LONG * __accept_addrlen __asm("a1") = (_accept_addrlen); \
  __asm volatile ("jsr a6@(-48:W)" \
  : "=r"(__accept__re) \
  : "r"(__accept__bn), "r"(__accept_sock), "r"(__accept_addr), "r"(__accept_addrlen)  \
  : "d1", "a0", "a1", "fp0", "fp1", "cc", "memory"); \
  __accept__re; \
  }); \
  _accept__re; \
})
It looks okay to me, though I'm certainly not an expert.

I obviously have a work-around for this specific problem, so there is no immediate need for a solution. The concern I have is that I might run into a similar problem in other bsdsocket.library interface functions as I get more of this code port functional.

Last edited by cdh; 27 December 2018 at 10:23. Reason: fix formatting
cdh is offline  
Old 27 December 2018, 11:14   #974
bebbo
botcher

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 389
it seems tha some macros do work and some don't.

The amiga-gcc provides ndk-include/inline/bsdsocket.h with
Code:
#define accept(sock, addr, addrlen) ({ \
  LONG _accept_sock = (sock); \
  struct sockaddr * _accept_addr = (addr); \
  socklen_t * _accept_addrlen = (addrlen); \
  LONG _accept__re = \
  ({ \
  register struct Library * const __accept__bn __asm("a6") = (struct Library *) (BSDSOCKET_BASE_NAME); register int _d1 __asm("d1"); register int _a0 __asm("a0"); register int _a1 __asm("a1");\
  register LONG __accept__re __asm("d0"); \
  register LONG __accept_sock __asm("d0") = (_accept_sock); \
  register struct sockaddr * __accept_addr __asm("a0") = (_accept_addr); \
  register socklen_t * __accept_addrlen __asm("a1") = (_accept_addrlen); \
  __asm volatile ("jsr a6@(-48:W)" \
  : "=r" (_d1), "=r" (_a0), "=r" (_a1),  "=r"(__accept__re) \
  : "r"(__accept__bn), "r"(__accept_sock), "r"(__accept_addr), "r"(__accept_addrlen) \
  : "fp0", "fp1", "cc", "memory"); \
  __accept__re; \
  }); \
  _accept__re; \
})
so regarding this example code:
Code:
#include <string.h>
#include <stdio.h>
#include <stdlib.h>

#include <unistd.h>

#include <netdb.h>
#include <unistd.h>
#include <sys/socket.h>
#include <sys/ioctl.h>
#include <netinet/in.h>
 
 
#include <inline/bsdsocket.h>
extern struct Library * SocketBase;

#if defined(C)
#define __SocketBase SocketBase
#define __accept(sock,addr,addrlen) ({ \
  LONG _accept_sock = (sock); \
  struct sockaddr * _accept_addr = (addr); \
  LONG * _accept_addrlen = (addrlen); \
  LONG _accept__re = \
  ({ \
  register struct Library * const __accept__bn __asm("a6") = (struct Library *) (__SocketBase);\
  register LONG __accept__re __asm("d0"); \
  register LONG __accept_sock __asm("d0") = (_accept_sock); \
  register struct sockaddr * __accept_addr __asm("a0") = (_accept_addr); \
  register LONG * __accept_addrlen __asm("a1") = (_accept_addrlen); \
  __asm volatile ("jsr a6@(-48:W)" \
  : "=r"(__accept__re) \
  : "r"(__accept__bn), "r"(__accept_sock), "r"(__accept_addr), "r"(__accept_addrlen)  \
  : "d1", "a0", "a1", "fp0", "fp1", "cc", "memory"); \
  __accept__re; \
  }); \
  _accept__re; \
})
#define foo __accept
#else
#define foo accept
#endif



int
myaccept(int sockfd,struct sockaddr *cliaddr,socklen_t *addrlen)
{
	int new_socket_fd = foo(sockfd, cliaddr, (LONG *)addrlen);

        if(new_socket_fd < 0)
        {
                puts("could not accept connection");
        }
	return new_socket_fd;
}
the result of
Code:
 m68k-amigaos-gcc -Os sock.c -S -o ndk.s
and
Code:
 m68k-amigaos-gcc -Os sock.c -S -o clib.s -DC
differs:
Code:
diff ndk.s clib.s
20d19
<       move.l d0,d2
so one of the macros triggers a bug - why?.

The difference is here:

ndk:
Code:
	jsr a6@(-48:W)
				|	0	  !*d0 !+d1                               !*a0 !*a1                  a5 !.a6   a7     !*f0 !*f1
vs

clib2
Code:
	jsr a6@(-48:W)
				|	20	  !*d0 !*d1                               !*a0 !*a1                  a5 !.a6   a7     !*f0 !*f1
with the ndk macro register d1 is marked as modified.
with the clib2 macro register d1 is marked as read and modified.

and this difference triggers a bug where my optimizer does not check for asm stuff and throws the superfluous assignment to d0 away :-)

guess I have to fix it...
bebbo is offline  
Old 27 December 2018, 11:37   #975
bebbo
botcher

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 389
ok, the fix is life.

And I still consider the ndk macro as more precise.

Last edited by bebbo; 27 December 2018 at 23:09.
bebbo is offline  
Old 27 December 2018, 21:08   #976
cdh
Registered User

 
Join Date: Dec 2017
Location: Los Altos, CA, USA
Posts: 6
Quote:
Originally Posted by bebbo View Post
ok, the fix is live.

And I still consider the ndk macro as more precise.

Thank you. I appreciate the quick fix and will be happy to test it once it lands -- I assume in one of the following repos:
https://github.com/bebbo/amiga-gcc

https://github.com/bebbo/gcc

https://github.com/bebbo/binutils-gdb
cdh is offline  
Old 28 December 2018, 03:43   #977
_dante_
Registered User

 
Join Date: Feb 2018
Location: Poland
Posts: 8
Quote:
Originally Posted by bebbo View Post
EDITH: I got _NSGetExecutablePath working.

but building libnix:
Code:
awk: ... makes too many open files
I pulled recent sources and on my mac the whole toolchain builds fine under the clang compiler from the latest Xcode.

Regarding the "awk: ... makes too many open files" - maybe usage of 'gawk' installed using 'brew' is getting rid of these errors, as I have it installed to override Apple's awk and I didn't get that error while building libnix.

More than that, using the toolchain compiled myself, I was able to compile 'hello' program with all available crt libs (newlib, clib2, libnix13 and libnix20) - so in terms of macOS support the toolchain seems to work now perfectly as expected!

Thanks Bebbo
_dante_ is online now  
Old 01 January 2019, 20:08   #978
arti
Registered User

 
Join Date: Jul 2008
Location: Poland
Posts: 548
I've took precompiled clib2 libraries from mac toolchain but all libs give error :
"Could not read symbols: File in wrong format." when linking.

My compiler is gcc 3.4.6.

Any idea why?
arti is offline  
Old 01 January 2019, 22:22   #979
Samurai_Crow
Total Chaos forever!

Samurai_Crow's Avatar
 
Join Date: Aug 2007
Location: Ft. Collins, CO USA
Age: 44
Posts: 1,281
Send a message via Yahoo to Samurai_Crow
Bebbo's GCC uses HUNK format like SAS/C and every other AmigaOS compiler. Earlier GCC versions used ELF formatted object code.
Samurai_Crow is offline  
Old 01 January 2019, 22:26   #980
bebbo
botcher

 
Join Date: Jun 2016
Location: Hamburg/Germany
Posts: 389
Quote:
Originally Posted by arti View Post
I've took precompiled clib2 libraries from mac toolchain but all libs give error :
"Could not read symbols: File in wrong format." when linking.

My compiler is gcc 3.4.6.

Any idea why?
your toolchain does not support the amiga hunk format.
bebbo is offline  
 


Currently Active Users Viewing This Thread: 2 (1 members and 1 guests)
Toni Wilen
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
New GCC based dev toolchain for AmigaOS 3.x cla Coders. Releases 8 24 December 2017 10:18
Issue with photon/xxxx WinUAE Toolchain arpz Coders. Asm / Hardware 2 26 September 2015 22:33
New 68k gcc toolchain arti Coders. C/C++ 17 31 July 2015 03:59
Hannibal's WinUAE Demo Toolchain 5 Bobic Amiga scene 1 23 July 2015 21:04
From gcc to vbcc. Cowcat Coders. General 9 06 June 2014 14:45

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 18:43.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Page generated in 0.14361 seconds with 16 queries