Jump to content
IGNORED

GCC for the TI


insomnia

Recommended Posts

Just as a note, I was able to use the install script to build this under the Linux Subsystem for Windows, except for the install step failed to find libc++. I didn't need that right now, so I just changed it not to build the c++ compiler, and it seemed to work. It was /really/ noisy, tons of pedantic warnings (all over the place, not just in the patches), but I didn't have to do anything special. Just wanted to try it and see if it worked better than Cygwin. ;)

  • Like 2
Link to comment
Share on other sites

  • 3 weeks later...

Hey everyone,

 

I've got a new set of patches for the compiler to send out. It's pretty thin, but that's a good thing.

 

Here's what's new:

 

Fixed a multiplication bug reported by Chue, In come cases, the input arguments were clobbered leading to a wrong result.

Fixed incorrect instruction sizes. This will result in better optimized code.

Added .size directive to calculate function sizes. This is helpful during development.

Reduced size of the patch file. This makes it easier to understand which changes were made to the baseline.

 

I've updated the GCC installer to use this latest patch, and added an updated "hello world" program. This program no longer needs the elf2cart tool, makes improvements to the crt0 as well as fixing some bugs in the vdp_copy_from_sys function.

 

Honestly, there's not much else to say here. The compiler is pretty mature and stable at this point, but I'm always interested to hear of any problems or opportunities for improvement.

  • Like 5
Link to comment
Share on other sites

  • 1 month later...

This is as much for future reference for myself as it is for anyone compiling on a macOS, but I needed to do three things in order to build the latest patch on my machine:

 

1. Edit the install script to invoke curl correctly by adding double quotes around the WGET variable assigned, and changing the curl option from -C to -O

2. Install gmp and mpfr libraries via Homebrew (brew install gmp mpfr)

3. remove the c++ build target. Unfortunately, c++ doesn't build with clang due to duplicate symbols. I don't need c++ for my use, so not a big problem, but something worth noting nonetheless. Perhaps this is related to the problem Tursi was seeing when building with the Linux Subsystem for Windows back in May?

  • Like 2
Link to comment
Share on other sites

  • 1 month later...

Played with the latest version a little bit, and I've discovered what I think might be a bug. I'm comparing patch 12 vs patch 15 here, and the assembler it outputs for this piece of C code:

 

bankswitch.h

#ifndef BANKSWITCH_H
#define BANKSWITCH_H

#define BANKSIZE	0x2000
#define BANKADDRESS 0x6000

// Variable to store our current bank, used by all trampoline functions
extern volatile unsigned int currentbank;

// Where to write to, to switch banks
// You can switch banks by addressing this as an array, and writing
// any value to it.
// 		e.g.	bankbase[2] = 1;
// This will switch to bank 2
extern volatile unsigned int *bankbase;

#endif

resource_copy.c:

#include "bankswitch.h"

#define _binary_start_bank	5

// Copy from cartridge ROM to a section in RAM
void rom_to_ram(unsigned long start, unsigned long end, unsigned char *dst)
{
	unsigned int srcoffset 	= (unsigned int)start % BANKSIZE;
	unsigned int length		= (unsigned int)(end - start);
	unsigned int srcbank	= _binary_start_bank + ((start - srcoffset) / BANKSIZE);

	// Do we need to read across different banks?
	while ( (srcoffset + length) > BANKSIZE )
	{
		unsigned int templength = BANKSIZE - srcoffset;

		// activate source bank
		bankbase[srcbank] = 1;

		// copy contents until end of bank
		memcpy(dst, (unsigned char*)(BANKADDRESS + srcoffset), templength);

		// update bank, offset and remaining length
		length -= templength;
		srcbank++;				// prime for next bank
		srcoffset = 0;			// start at start of bank
		dst += templength;		// Move destination pointer
	}

	// Copy contents of one (last) bank
	bankbase[srcbank] = 1;
	memcpy(dst, (void*)(BANKADDRESS + srcoffset), length);

	// Restore bank
	bankbase[currentbank] = 1;
}

When compiled with patch 12, the code works perfectly fine (it is, as I'm sure is obvious to most, code to copy binary blobs from paged cartridge ROM to RAM). When compiled with patch 15, it copies garbage (haven't been able to identify where it goes wrong). So as a first step to debug this, I figured I'd look at the assembly code generated by the two compilers.

 

For patch 12:

000000ba <rom_to_ram>:
  ba:	02 2a ff f2 	ai r10, >FFF2
  be:	c0 0a       	mov r10, r0
  c0:	cc 0b       	mov r11, *r0+
  c2:	cc 09       	mov r9, *r0+
  c4:	cc 0d       	mov r13, *r0+
  c6:	cc 0e       	mov r14, *r0+
  c8:	c4 0f       	mov r15, *r0
  ca:	c1 81       	mov r1, r6
  cc:	c1 c2       	mov r2, r7
  ce:	c3 85       	mov r5, r14
  d0:	c2 02       	mov r2, r8
  d2:	02 48 1f ff 	andi r8, >1FFF
  d6:	c3 44       	mov r4, r13
  d8:	63 42       	s r2, r13
  da:	c0 88       	mov r8, r2
  dc:	04 c1       	clr r1
  de:	61 81       	s r1, r6
  e0:	61 c2       	s r2, r7
  e2:	18 00       	joc 0
  e4:	06 06       	dec r6
  e6:	c2 46       	mov r6, r9
  e8:	0a 39       	sla r9, 3
  ea:	c0 47       	mov r7, r1
  ec:	09 d1       	srl r1, 13
  ee:	e2 41       	soc r1, r9
  f0:	02 29 00 05 	ai r9, >0005
  f4:	c3 c9       	mov r9, r15
  f6:	a3 c9       	a r9, r15
  f8:	02 04 00 00 	li r4, >0000
  fc:	10 00       	jmp 0

000000fe <L8>:
  fe:	02 28 e0 00 	ai r8, >E000
 102:	05 08       	neg r8
 104:	c0 60 00 00 	mov @>0000, r1
 108:	a0 4f       	a r15, r1
 10a:	02 03 00 01 	li r3, >0001
 10e:	c4 43       	mov r3, *r1
 110:	c0 4e       	mov r14, r1
 112:	c0 c8       	mov r8, r3
 114:	ca 84 00 0c 	mov r4, @>000C(r10)
 118:	ca 88 00 0a 	mov r8, @>000A(r10)
 11c:	06 94       	bl *r4
 11e:	c2 2a 00 0a 	mov @>000A(r10), r8
 122:	63 48       	s r8, r13
 124:	05 89       	inc r9
 126:	a3 88       	a r8, r14
 128:	05 cf       	inct r15
 12a:	04 c8       	clr r8
 12c:	c1 2a 00 0c 	mov @>000C(r10), r4

00000130 <L7>:
 130:	c0 4d       	mov r13, r1
 132:	a0 48       	a r8, r1
 134:	c0 88       	mov r8, r2
 136:	02 22 60 00 	ai r2, >6000
 13a:	02 81 20 00 	ci r1, >2000
 13e:	1b 00       	jh 0
 140:	a2 49       	a r9, r9
 142:	a2 60 00 00 	a @>0000, r9
 146:	02 01 00 01 	li r1, >0001
 14a:	c6 41       	mov r1, *r9
 14c:	c0 4e       	mov r14, r1
 14e:	c0 cd       	mov r13, r3
 150:	06 a0 00 00 	bl @>0000
 154:	c0 60 00 00 	mov @>0000, r1
 158:	a0 41       	a r1, r1
 15a:	a0 60 00 00 	a @>0000, r1
 15e:	02 02 00 01 	li r2, >0001
 162:	c4 42       	mov r2, *r1
 164:	c2 fa       	mov *r10+, r11
 166:	c2 7a       	mov *r10+, r9
 168:	c3 7a       	mov *r10+, r13
 16a:	c3 ba       	mov *r10+, r14
 16c:	c3 da       	mov *r10, r15
 16e:	02 2a 00 06 	ai r10, >0006
 172:	04 5b       	b *r11

For patch 15:

000000bc <rom_to_ram>:
  bc:	02 2a ff f2 	ai r10, >FFF2
  c0:	c0 0a       	mov r10, r0
  c2:	cc 0b       	mov r11, *r0+
  c4:	cc 09       	mov r9, *r0+
  c6:	cc 0d       	mov r13, *r0+
  c8:	cc 0e       	mov r14, *r0+
  ca:	c4 0f       	mov r15, *r0
  cc:	c1 81       	mov r1, r6
  ce:	c1 c2       	mov r2, r7
  d0:	c3 85       	mov r5, r14
  d2:	c2 02       	mov r2, r8
  d4:	02 48 1f ff 	andi r8, >1FFF
  d8:	c3 44       	mov r4, r13
  da:	63 42       	s r2, r13
  dc:	c0 88       	mov r8, r2
  de:	04 c1       	clr r1
  e0:	61 81       	s r1, r6
  e2:	61 c2       	s r2, r7
  e4:	18 00       	joc 0
  e6:	06 06       	dec r6
  e8:	c0 87       	mov r7, r2
  ea:	08 d6       	sra r6, 13
  ec:	09 d7       	srl r7, 13
  ee:	0a 32       	sla r2, 3
  f0:	e1 c2       	soc r2, r7
  f2:	c2 47       	mov r7, r9
  f4:	02 29 00 05 	ai r9, >0005
  f8:	c3 c9       	mov r9, r15
  fa:	a3 c9       	a r9, r15
  fc:	02 04 00 00 	li r4, >0000
 100:	10 00       	jmp 0

00000102 <L8>:
 102:	02 28 e0 00 	ai r8, >E000
 106:	05 08       	neg r8
 108:	c0 60 00 00 	mov @>0000, r1
 10c:	a0 4f       	a r15, r1
 10e:	02 03 00 01 	li r3, >0001
 112:	c4 43       	mov r3, *r1
 114:	c0 4e       	mov r14, r1
 116:	c0 c8       	mov r8, r3
 118:	ca 84 00 0c 	mov r4, @>000C(r10)
 11c:	ca 88 00 0a 	mov r8, @>000A(r10)
 120:	06 94       	bl *r4
 122:	c2 2a 00 0a 	mov @>000A(r10), r8
 126:	63 48       	s r8, r13
 128:	05 89       	inc r9
 12a:	a3 88       	a r8, r14
 12c:	05 cf       	inct r15
 12e:	04 c8       	clr r8
 130:	c1 2a 00 0c 	mov @>000C(r10), r4

00000134 <L7>:
 134:	c0 4d       	mov r13, r1
 136:	a0 48       	a r8, r1
 138:	c0 88       	mov r8, r2
 13a:	02 22 60 00 	ai r2, >6000
 13e:	02 81 20 00 	ci r1, >2000
 142:	1b 00       	jh 0
 144:	a2 49       	a r9, r9
 146:	a2 60 00 00 	a @>0000, r9
 14a:	02 01 00 01 	li r1, >0001
 14e:	c6 41       	mov r1, *r9
 150:	c0 4e       	mov r14, r1
 152:	c0 cd       	mov r13, r3
 154:	06 a0 00 00 	bl @>0000
 158:	c0 60 00 00 	mov @>0000, r1
 15c:	a0 41       	a r1, r1
 15e:	a0 60 00 00 	a @>0000, r1
 162:	02 02 00 01 	li r2, >0001
 166:	c4 42       	mov r2, *r1
 168:	c2 fa       	mov *r10+, r11
 16a:	c2 7a       	mov *r10+, r9
 16c:	c3 7a       	mov *r10+, r13
 16e:	c3 ba       	mov *r10+, r14
 170:	c3 da       	mov *r10, r15
 172:	02 2a 00 06 	ai r10, >0006
 176:	04 5b       	b *r11

That's as far as I got. You'll notice the code is largely the same, except for right after line 20 (adress 0x0bc and 0x0ba in the respective disassemblies), where there's a small difference in generated code (patch 15 is slightly longer).

  • Like 1
Link to comment
Share on other sites

OK, I found the problem in the compiler. The issue is that there was a bug with right shifts of 32-bit values.

 

Here's how I found the problem:

 

After doing a diff between the two assembly snippets, there was only one mismatched block:

patch 12  (works)
  e6:	c2 46       	mov r6, r9
  e8:	0a 39       	sla r9, 3
  ea:	c0 47       	mov r7, r1      
  ec:	09 d1       	srl r1, 13
  ee:	e2 41       	soc r1, r9

patch 15 (fails)
  e8:	c0 87       	mov r7, r2     
  ea:	08 d6       	sra r6, 13
  ec:	09 d7       	srl r7, 13
  ee:	0a 32       	sla r2, 3
  f0:	e1 c2       	soc r2, r7

From looking at the source code and surrounding assembly, I was able to determine this block of code was part of the command:

unsigned int srcbank    = _binary_start_bank + ((start - srcoffset) / BANKSIZE);

Specifically, this code implemented ((start - srcoffset) / BANKSIZE. The (start - srcoffset) calculation was done by the instructions between offsets 0xde and 0xe4. This leaves us with (N / BANKSIZE). Since BANKSIZE is a power of two, the compiler uses a bit shift to do the division, transforming the code into (N >> 13).

 

Knowing all this, lets walk through the code to see what's going on.

1) Assume a bit pattern stored in R6 and R7

   .----r6--------. .----r7--------.
   abcdefghijklmnop qrstuvwxyzABCDEF

2) By manual calculation, we should have this result:

   0000000000000abc defghijklmnopqrs


3) Trace the code

                        Assembly        Pseudo        bitfield value
patch 12  (works)       ----------      ----------    ----------------
  e6:	c2 46       	mov r6, r9
  e8:	0a 39       	sla r9, 3       r9 = r6<<3  = defghijklmnop000
  ea:	c0 47       	mov r7, r1      
  ec:	09 d1       	srl r1, 13      r1 = r7>>13 = 0000000000000qrs
  ee:	e2 41       	soc r1, r9      r9 |= r1    = defghijklmnopqrs  <-- Correct!


                        Assembly        Pseudo        bitfield value
patch 15 (fails)        ----------      ----------    ----------------
  e8:	c0 87       	mov r7, r2      r2 = r7     = qrstuvwxyzABCDEF  <-- Should use r6, not r7
  ea:	08 d6       	sra r6, 13      r6 = r6>>13 = 0000000000000abc
  ec:	09 d7       	srl r7, 13      r7 = r7>>13 = 0000000000000qrs
  ee:	0a 32       	sla r2, 3       r2 = r7<<3  = tuvwxyzABCDEF000
  f0:	e1 c2       	soc r2, r7      
  f2:	c2 47       	mov r7, r9      r9 = r7|r2  = tuvwxyzABCDEFqrs  <-- Wrong!

Ultimately, this was a typo in the format used for this instruction, and has been fixed. I'll look for similar problems in the other shift instructions and get a new patch sent out in a day or two.

 

Thanks for the bug report Mole! If anyone finds anything else, those fixes will get included too.

 

 

  • Like 7
Link to comment
Share on other sites

Well, it's patch time again.

 

The first post of this thread has been updated with the newest patch file and an updated installer script.

 

Here's the changes in this latest set:

Fixed 32-bit right constant shift, failed with some constants
Fixed all 32-bit variable shifts, was using r0 as temp register
Fixed carry bit in 32-bit add
Fixed invalid instruction in some 32-bit add forms

The first one is a result of the bug TheMole reported earlier. Not much more to say about that one.

 

While testing shift instructions, I found that in some cases the compiler decided to use R0 as a temp register before the final calculation was complete. I'm still not sure why that was happening, since R0 was supposed to be the last register selected for temp registers. This was fixed by disallowing input registers as temps.

 

Another unexpected bug was that the carry between the low and high words was inverted, resulting in strange results.

 

There was another edge case where the compiler tried to use the AI instruction with memory addresses. This was fixed by the use of a temp register.

 

It looks like the only bugs left are in unusual edge cases, which is great. I'm still trying to find improvements, but at this point, it's getting hard to find clear improvements. So if anyone has a good idea, I'd be happy to hear it.

 

 

  • Like 1
Link to comment
Share on other sites

Well, it's patch time again.

 

The first post of this thread has been updated with the newest patch file and an updated installer script.

 

Here's the changes in this latest set:

Fixed 32-bit right constant shift, failed with some constants
Fixed all 32-bit variable shifts, was using r0 as temp register
Fixed carry bit in 32-bit add
Fixed invalid instruction in some 32-bit add forms

The first one is a result of the bug TheMole reported earlier. Not much more to say about that one.

 

While testing shift instructions, I found that in some cases the compiler decided to use R0 as a temp register before the final calculation was complete. I'm still not sure why that was happening, since R0 was supposed to be the last register selected for temp registers. This was fixed by disallowing input registers as temps.

 

Another unexpected bug was that the carry between the low and high words was inverted, resulting in strange results.

 

There was another edge case where the compiler tried to use the AI instruction with memory addresses. This was fixed by the use of a temp register.

 

It looks like the only bugs left are in unusual edge cases, which is great. I'm still trying to find improvements, but at this point, it's getting hard to find clear improvements. So if anyone has a good idea, I'd be happy to hear it.

 

 

  • Like 1
Link to comment
Share on other sites

Well, it's patch time again.

 

The first post of this thread has been updated with the newest patch file and an updated installer script.

 

Here's the changes in this latest set:

Fixed 32-bit right constant shift, failed with some constants
Fixed all 32-bit variable shifts, was using r0 as temp register
Fixed carry bit in 32-bit add
Fixed invalid instruction in some 32-bit add forms

The first one is a result of the bug TheMole reported earlier. Not much more to say about that one.

 

While testing shift instructions, I found that in some cases the compiler decided to use R0 as a temp register before the final calculation was complete. I'm still not sure why that was happening, since R0 was supposed to be the last register selected for temp registers. This was fixed by disallowing input registers as temps.

 

Another unexpected bug was that the carry between the low and high words was inverted, resulting in strange results.

 

There was another edge case where the compiler tried to use the AI instruction with memory addresses. This was fixed by the use of a temp register.

 

It looks like the only bugs left are in unusual edge cases, which is great. I'm still trying to find improvements, but at this point, it's getting hard to find clear improvements. So if anyone has a good idea, I'd be happy to hear it.

 

 

  • Like 4
Link to comment
Share on other sites

  • 2 weeks later...

I'm seeing a number of issues with this patch (some of which might have been there in previous versions as well, since I haven't gotten this far into compiling and running the program with previous versions).

 

First off, I get a segfault while compiling certain larger code files. Not sure if it is truly related to the length of the file, or just an unfortunate arrangement of code, but commenting out certain functions (and stripping out their use) will make the segfault go away. I can provide a code file that triggers this if it helps.

 

Secondly, there seems to still be some funky math going on. I need to investigate further, but without changing any code a number of calculations have seemingly different results compared to patch 12, which brakes a number of things in the game. I tried to find an as simple as possible specific piece of code that has a different outcome in both versions, and this is an instance:

int cnt, y;

cnt = 180;
while (cnt--)
{
	y = (cnt % 16) - 8;

	// Bounce arrow
	// maplocation_y is an unsigned char
	if (y >= 0)
		vdpchar(0x1F80, levels[currentlevel -1].maplocation_y + (y / 2));
	else
		vdpchar(0x1F80, levels[currentlevel -1].maplocation_y - (y / 2));
}

This code simply bounces a sprite up and down on the screen, and the bounce is different in both versions. The "range" of calculated y-values is visible wider (it bounces more) and shifted towards the bottom of the screen somewhat.

 

Now, if I change the definition of y from "int" to "char", it actually does the right thing (even if "cnt" stays a 16-bit integer). Alternatively, if I explicitly cast the result of the (y / 2) calculation to char (right before adding it to the maplocation_y struct member in the vdpchar function call), it also works. So I think something is wrong with some of the word-to-byte casts.

 

It's a simple fix in the above case, but I often go from words to bytes in my code (mostly when pushing things to the VDP), and the latest patch breaks this code in numerous places where a fix isn't so simple: collision detection, sprite rendering, ...

 

Anyway, great progress so far, and it's awesome to see that you keep swatting these bugs. I hope my reports aren't too disheartening :).

Edited by TheMole
  • Like 2
Link to comment
Share on other sites

  • 2 months later...

Hi everyone!

The current installer fails to build binutils :-(
I am using the very latest Cygwin version and the installer found on this thread.
I do not understand the error?
What do I need to have a working build for Cygwin?

 

After more othan one hour I get the following error:

...
texi:11: raising the section level of @subsubsection which is too low

make[3]: *** [Makefile:394: bfd.info] Error 1...
Remark: I have textinfo in my Cygwin installation.

Fabrizio
Edited by Fabrizio Caruso
Link to comment
Share on other sites

What are the necessary steps to install GCC for TI on the latest Cygwin environemnt?

The current script fails at building binutils:

rm -rf $backupdir; exit $rc
./elf.texi:11: raising the section level of @subsubsection which is too low
make[3]: *** [Makefile:394: bfd.info] Error 1
make[3]: Leaving directory '/cygdrive/c/Users/Brizio/Retro/gcc-installer/build/binutils-2.19.1/bfd/doc'
Making info in po
make[3]: Entering directory '/cygdrive/c/Users/Brizio/Retro/gcc-installer/build/binutils-2.19.1/bfd/po'
make[3]: Nothing to be done for 'info'.
make[3]: Leaving directory '/cygdrive/c/Users/Brizio/Retro/gcc-installer/build/binutils-2.19.1/bfd/po'
make[3]: Entering directory '/cygdrive/c/Users/Brizio/Retro/gcc-installer/build/binutils-2.19.1/bfd'
make[3]: Nothing to be done for 'info-am'.
make[3]: Leaving directory '/cygdrive/c/Users/Brizio/Retro/gcc-installer/build/binutils-2.19.1/bfd'
make[2]: *** [Makefile:1094: info-recursive] Error 1
make[2]: Leaving directory '/cygdrive/c/Users/Brizio/Retro/gcc-installer/build/binutils-2.19.1/bfd'
make[1]: *** [Makefile:3100: all-bfd] Error 2
make[1]: Leaving directory '/cygdrive/c/Users/Brizio/Retro/gcc-installer/build/binutils-2.19.1'
make: *** [Makefile:723: all] Error 2
Link to comment
Share on other sites

I installed a new Cygwin environment (2.9.0) on my machine and gave this a try... I had a couple of problems with some of the scripts not liking line endings (dos2unix or unix2dos fixed those... afraid I didn't do it scientifically). Then I ran into issues with the Configure scripts hanging. That turned out to be Configure finding Windows applications in my path, because Cygwin kept the whole Windows path as well. I changed my path to include only Cygwin paths and everything ran through clean after that.

 

I've zipped up my folder for you and anyone else -- this is the .16 patch so be aware of TheMole's notes above. It's meant to be installed into /home/tms9900 (it includes the tms9900 folder, so unpack into the /home/ folder). I've only tested it against libti99, but it seems to run okay. No warranties, no promises, etcetc, but hope it gets you past this step. :)

 

tms9900.rar

  • Like 2
Link to comment
Share on other sites

I tried again to install it GCC for TI with the latest installer in Cygwin in a different directory but I still get the same problem (see below).

What should I do with dos2unix? Run it with the patch files and/or the installer script?

Could you please tell what are the necessary steps to install GCC for TI in Cygwin?

./elf.texi:11: raising the section level of @subsubsection which is too low
make[3]: *** [Makefile:394: bfd.info] Error 1
make[3]: Leaving directory '/home/fcaruso/build/binutils-2.19.1/bfd/doc'
Making info in po
make[3]: Entering directory '/home/fcaruso/build/binutils-2.19.1/bfd/po'
( if test 'x../.././bfd/po' != 'x.'; then \
posrcprefix='../.././bfd/'; \
else \
posrcprefix="../"; \
fi; \
rm -f SRC-POTFILES-t SRC-POTFILES \
&& (sed -e '/^#/d' \
-e '/^[ ]*$/d' \
-e "s@.*@ $posrcprefix& \\\\@" < ../.././bfd/po/SRC-POTFILES.in \
| sed -e '$s/\\$//') > SRC-POTFILES-t \
&& chmod a-w SRC-POTFILES-t \
&& mv SRC-POTFILES-t SRC-POTFILES )
( rm -f BLD-POTFILES-t BLD-POTFILES \
&& (sed -e '/^#/d' \
-e '/^[ ]*$/d' \
-e "s@.*@ ../& \\\\@" < ../.././bfd/po/BLD-POTFILES.in \
| sed -e '$s/\\$//') > BLD-POTFILES-t \
&& chmod a-w BLD-POTFILES-t \
&& mv BLD-POTFILES-t BLD-POTFILES )
cd .. \
&& CONFIG_FILES=po/Makefile.in:po/Make-in \
CONFIG_HEADERS= /bin/sh ./config.status
config.status: creating po/Makefile.in
config.status: executing depfiles commands
config.status: executing libtool commands
config.status: executing default-1 commands
config.status: executing bfd_stdint.h commands
config.status: executing default commands
make[3]: Nothing to be done for 'info'.
make[3]: Leaving directory '/home/fcaruso/build/binutils-2.19.1/bfd/po'
make[3]: Entering directory '/home/fcaruso/build/binutils-2.19.1/bfd'
make[3]: Nothing to be done for 'info-am'.
make[3]: Leaving directory '/home/fcaruso/build/binutils-2.19.1/bfd'
make[2]: *** [Makefile:1094: info-recursive] Error 1
make[2]: Leaving directory '/home/fcaruso/build/binutils-2.19.1/bfd'
make[1]: *** [Makefile:3100: all-bfd] Error 2
make[1]: Leaving directory '/home/fcaruso/build/binutils-2.19.1'
make: *** [Makefile:723: all] Error 2
=== Failed to build Binutils ===

Edited by Fabrizio Caruso
Link to comment
Share on other sites

Out of desperation I have also tried to run the installer script in a virtualized Linux but it does not work, either:
It produces some warnings about unrecognized operators.
It says installation complete but I cannot find any compiler in any of the bin directories of the output directory.

 

I am using an old Ubuntu
uname -r

3.5.0-17-generic.

 

What do I need to install GCC for TI?

It seems the installer does not work with either Cygwin nor a virtualized Ubuntu... :-(

Maybe a special version is required...
Could you please tell me what your specific successful configuration was?

Edited by Fabrizio Caruso
Link to comment
Share on other sites

I have it installed under Fedora 25. Here is what I used - note that I did get a small error with some directories needing to be manually created.

dnf update -y
dnf groupinstall "C Development Tools and Libraries"
dnf install wget bzip2 patch tree
dnf install gmp  gmp-devel  mpfr  mpfr-devel  libmpc  libmpc-devel
./install.sh /usr/local/bin/gccti

The above produces the error:

/bin/sh: line 3: cd: tms9900/libstdc++-v3: No such file or directory

Which is fixed by creating some directories and re-running the install:

mkdir build/gcc-4.4.0/build/libiberty/
mkdir build/gcc-4.4.0/build/libiberty/tms9900
mkdir build/gcc-4.4.0/build/libiberty/tms9900/libstdc++-v3

./install.sh /usr/local/bin/gccti
Edited by chue
Link to comment
Share on other sites

I've thrown together a small linux server that has gcc pre-installed. The idea is that those who want to use the compiler but are having problems installing the patch/compiling the build can ask me for an account on the server and build their programs there. It has tms9900-gcc, libti99 and xdt99 pre-installed, along with a bunch of other dev tools, so it should have all the tools needed to do basic development.

 

The server sits here: http://5.230.195.16/and can be accessed through ssh.

If anyone is interested in an account, send me a PM and I'll happily provide you one.

 

Hope this is of help for those that want to dabble with gcc for the TI without having to build it themselves!

  • Like 7
Link to comment
Share on other sites

Thanks a lot!
As a last resort, I will use a server but there must be a way to install it.

 

Nothing seems to work:
- The script in Cygwin fails with a makefile error
- Under two different Ubuntu distributions, the script is completed but no compiler is generated

We should try to build a working script or at least find a sequence of steps to install on it on most Linux distros?

Edited by Fabrizio Caruso
Link to comment
Share on other sites

Under Ubuntu:
checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 $$f2
checking for correct version of gmp.h... no
configure: error: Building GCC requires GMP 4.1+ and MPFR 2.3.2+.
Try the --with-gmp and/or --with-mpfr options to specify their locations.
Copies of these libraries' source code can be found at their respective
hosting sites as well as at ftp://gcc.gnu.org/pub/gcc/infrastructure/.
See also http://gcc.gnu.org/install/prerequisites.htmlfor additional info.
If you obtained GMP and/or MPFR from a vendor distribution package, make
sure that you have installed both the libraries and the header files.
They may be located in separate packages.
./install.sh: 26: [: 1: unexpected operator
make: *** No rule to make target 'all-gcc'. Stop.
./install.sh: 26: [: 2: unexpected operator
make: *** No rule to make target 'install'. Stop.
=== Installation complete ===

Link to comment
Share on other sites

Not enought, yet.

The script is not creating the frequired sub-directory structure (other users have reported the same problem):

 

/bin/bash: line 3: cd: tms9900/libstdc++-v3: No such file or directory
Makefile:10623: recipe for target 'install-target-libstdc++-v3' failed
make[1]: *** [install-target-libstdc++-v3] Error 1
make[1]: Leaving directory '/home/brizio/RETRO/install_stuff/build/gcc-4.4.0/build'
Makefile:2475: recipe for target 'install' failed
make: *** [install] Error 2
=== Installation complete ===

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...