Home | Docs | Forums | Lists | Bugs | Planet | Store | GMN | Get Gentoo!
Not eligible to see or edit group visibility for this bug.
View Bug Activity | Format For Printing | XML | Clone This Bug
http://tigcc.ticalc.org/linux/
Created an attachment (id=31497) [edit] dev-embedded/tigcc-0.95_beta8.ebuild tested on amd64, should be fine on x86
Description: TIGCC is mainly a C compiler for the Texas Instruments TI-89 and TI-92 Plus calculators. It is based on GCC, the GNU Compiler Collection. See http://tigcc.ticalc.org http://tigcc.ticalc.org/linux
Wow. What are the odds we were both working on an ebuild for TIGCC this past week. I was just about to post mine. Guess there's not much point now. One question though: Isn't this going to break when the new version of tigcc is released and the tigcc_src.tar.bz2 file is replaced?
I tested it on x86 and it seems to work pretty well. A couple of minor questions. Why doesn't it do the doc directory like everything else? The files aren't gzipped and they're inside a doc subdirectory inside /usr/share/tigcc-0.95_beta8. Also, any thoughts on whether it perhaps should be in /usr/local/tigcc instead of /usr/tigcc? Neither of these things are paramount, just inquiries...
Created an attachment (id=31515) [edit] new ebuild, some minor fixes and comments added It *will* break if tigcc_src.tar.bz2 file is replaced, as they just provide this one file for download. I wanted the docs not to be in /usr/tigcc/doc, so I put them where I thought they would belong to. I don't know whether this is the right way, I'm listening to all suggestions. I don't think that it matters if tigcc is put in /usr or /usr/local. Perhaps it should be put into /opt, as the xmingw ebuild does?
I think if we attach the program, the developer can put it on the gentoo mirror with the correct name. Then it could be tigcc-0.95_beta8.tar.bz2. As for me, I put it on my website temporarily. As for the docs, I didn't use the install script for mine. I'll post it so you can see what I did, but maybe it's not important. Also, env-update is run automatically by emerge. Doesn't seem to be a reason to tell people to do this. Also, why do you remove the flags? There doesn't seem to be a reason to force -Os on people. -O2 works fine, unless you've seen otherwise. I think this should be removed. What are flashosa and libfargo? Finally, why have the env.d file by 05? Was this because gcc was also 05? This doesn't cause problems for me, but I wonder if it could potentially cause problems for someone who has gcc listed later on. Can this happen I wonder? I made my env.d script 50tigcc. Again, maybe this is moot; I don't know. Let's see if I can post this before the server goes down again...
Created an attachment (id=31546) [edit] ebuild without using tigcc install script directly
Some quick comments while I'm downloading: Doc dir should be /usr/share/tigcc-0.95_beta8 as john suggested in comment #4. Don't use /usr/local in gentoo. /opt is for binary packages and /usr/bin otherwise. I'd rather not see any conflicts with tigcc and gcc. I haven't looked into this totally. If you want to use tigcc like a gcc for packages look at gcc-config and work out a config file for that. SRC_URI - use mirror://gnu/gcc/releases/gcc-3.3.3/gcc-core-3.3.3.tar.bz2 for commonly mirrored stuff. Maybe a full version of binutils i.e. binutils-2.14.90.0.6.tar.bz2 src_unpack() { unpack ${A} } Is the default unpacker so you can omit this function if this is all it does. With depends - if you DEPEND on bison or somethings that is only used in the compulation add a RDEPEND to point to the runtime dependancies (virtual/glibc). Thats all for now. and I'm working on it. Don't worry about putting a new ebuild here - just remember for next time. Will let you know if I get stuck.
Created an attachment (id=31634) [edit] ebuild.patch Ok this is the changes that I have made so far. What is required: move /usr/local/tigcc/include to /usr/include/tigcc binutils stuff should be in /usr/ti-linux-gnu/bin move /usr/local/tigcc/bin to /usr/ti-linux-gnu/tigcc-bin/3.3 move /usr/local/tigcc/lib to /usr/lib (shouldn't be any conflicts) move /usr/local/tigcc/examples/ to either /usr/share/doc/tigcc-0.95_beta8/examples or /usr/share/tigcc Look at /etc/env.d/gcc/i* for a same env file.
Created an attachment (id=31650) [edit] ebuild.patch - incorporates Daniel's patch John, your ebuild fails here with: /var/tmp/portage/tigcc-0.95_beta8/work/build/gcc/gcc/xgcc -B/var/tmp/portage/tigcc-0.95_beta8/work/build/gcc/gcc/ -B/usr/local/m68k-coff/bin/ -B/usr/local/m68k-coff/lib/ -isystem /usr/local/m68k-coff/include -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -isystem ./include -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -I. -I. -I/var/tmp/portage/tigcc-0.95_beta8/work/gcc-3.3.3/gcc -I/var/tmp/portage/tigcc-0.95_beta8/work/gcc-3.3.3/gcc/. -I/var/tmp/portage/tigcc-0.95_beta8/work/gcc-3.3.3/gcc/config -I/var/tmp/portage/tigcc-0.95_beta8/work/gcc-3.3.3/gcc/../include -DL_negdi2 -c /var/tmp/portage/tigcc-0.95_beta8/work/gcc-3.3.3/gcc/libgcc2.c -o libgcc/./_negdi2.o In file included from /var/tmp/portage/tigcc-0.95_beta8/work/gcc-3.3.3/gcc/config/m68k/m68k-ti.h:27, from /var/tmp/portage/tigcc-0.95_beta8/work/gcc-3.3.3/gcc/config/m68k/m68k-coff.h:37, from tconfig.h:16, from /var/tmp/portage/tigcc-0.95_beta8/work/gcc-3.3.3/gcc/libgcc2.c:36: /var/tmp/portage/tigcc-0.95_beta8/work/gcc-3.3.3/gcc/config/smapbcd.h:24:33: math.h: No such file or directory In file included from /var/tmp/portage/tigcc-0.95_beta8/work/gcc-3.3.3/gcc/libgcc2.c:44: /var/tmp/portage/tigcc-0.95_beta8/work/gcc-3.3.3/gcc/libgcc2.h:102: error: no data type for mode `SF' /var/tmp/portage/tigcc-0.95_beta8/work/gcc-3.3.3/gcc/libgcc2.h:103: error: no data type for mode `DF' In file included from /var/tmp/portage/tigcc-0.95_beta8/work/gcc-3.3.3/gcc/config/m68k/m68k-ti.h:27, from /var/tmp/portage/tigcc-0.95_beta8/work/gcc-3.3.3/gcc/config/m68k/m68k-coff.h:37, from tconfig.h:16, from /var/tmp/portage/tigcc-0.95_beta8/work/gcc-3.3.3/gcc/libgcc2.c:36: /var/tmp/portage/tigcc-0.95_beta8/work/gcc-3.3.3/gcc/config/smapbcd.h:24:33: math.h: No such file or directory make[2]: *** [libgcc/./_muldi3.o] Error 1 make[2]: *** Waiting for unfinished jobs.... In file included from /var/tmp/portage/tigcc-0.95_beta8/work/gcc-3.3.3/gcc/libgcc2.c:44: /var/tmp/portage/tigcc-0.95_beta8/work/gcc-3.3.3/gcc/libgcc2.h:102: error: no data type for mode `SF' /var/tmp/portage/tigcc-0.95_beta8/work/gcc-3.3.3/gcc/libgcc2.h:103: error: no data type for mode `DF' make[2]: *** [libgcc/./_negdi2.o] Error 1 make[2]: Leaving directory `/var/tmp/portage/tigcc-0.95_beta8/work/build/gcc/gcc' make[1]: *** [stmp-multilib] Error 2 make[1]: Leaving directory `/var/tmp/portage/tigcc-0.95_beta8/work/build/gcc/gcc' make: *** [all-gcc] Error 2 !!! ERROR: dev-embedded/tigcc-0.95_beta8 failed. !!! Function src_compile, Line 60, Exitcode 2 !!! (no error message) I made some slight modifications, and fixed the assembler error already. Building gcc failed because it didn't use the newly built assembler, I fixed this. But I have no idea to get around the error above.
GCC installation is supposed to fail at a certain point. Not sure why this is, but it has always been this way in TIGCC. It doesn't seem to affect the program.
Okay. There are a few minor problems. First, the tigcc front-end and other utils are very dependent upon everything being relative to a single path. e.g. bin and lib and include cannot be separated from this directory, unless maybe if symlinks are made. Should another directory be created with symlinks, or should there just be some directory. You don't seem to like /usr/local. Is /usr/tigcc better? This directory that contains bin, lib, and include must exist for the tigcc utilities to work. I don't understand the reasoning behind gcc-config. What is this for? My understanding is that you could have two versions of gcc installed simultanouelsy. a) What is the purpose of this when only root can change gcc-config? This would bar any regular user from using tigcc. b) This version of gcc is not in competition. You cannot choose to use one over the other. The system gcc must be used to compile things for the system. TIGCC can only be used to cross-compile for the calculators. Also. What is binutils-2.14.xxxx? These are not from gnu (they're not on ftp.gnu.org anyway), and the ChangeLog indicates they contain patches. This doens't seem like a good idea for tigcc as it uses its own patches. If the || die part of emake || die on compiling gcc is removed it will finish. This error is unavoidable (or maybe it is avoidable, but it has always existed, so I don't consider this a problem).
Created an attachment (id=32042) [edit] new version, requires a68k-fix.patch This ebuild installs tigcc to the destination Daniel suggested. To cope with the hardcoded paths in the tigcc sources I just created symlinks. This ebuild doesn't use gcc-config, as I don't see any reason to do this. I tried this, and left a way to quickly switch to that behaviour, but I don't think that's a good idea because tigcc is a cross compiler. Can someone try to compile Windows.c with 'tprbuilder Windows.tpr'? (it's in the examples directory) It gives me this: hephaestos root # tprbuilder Windows.tpr tprbuilder: tigcc Windows.c -o "Windows" -n Windows -Os -Wall -W -Wwrite-strings -WA,-k,-g,-t --optimize-nops --optimize-returns --optimize-branches --optimize-moves --optimize-tests --optimize-calcs --remove-unused --flash-os -DKERNEL_FORMAT_BSS -DKERNEL_FORMAT_DATA_VAR Warning: Flash OS support in TIGCC is experimental. Warning: Unresolved global import `__startup_code'. Warning: Unresolved global import `__kernel_format_data_var'. Warning: Unresolved global import `__nostub'. Warning: Unresolved global import `__kernel_format_bss'. Warning: Unresolved global import `__kernel_format_rom_calls'. Warning: Unresolved global import `__set_file_in_use_bit'. Error: Support for `.??u' files is not implemented yet. Use `--outputbin'. http://p080.ezboard.com/ftichessteamhqfrm5.showMessage?topicID=2608.topic In the document I linked here, a way to fix this is described, (i. e. installing flashos.a) but doesn't seem to work. I copied this file to tigcc's libdir after building it, but this error persists.
Created an attachment (id=32043) [edit] a68k-fix.patch
tprbuilder does not seem to call the linker with the tigcc library. This has been a problem with all the programs I've tried to build. I think it's a TIGCC bug, not an ebuild bug though. I think it needs to be reported to the TIGCC team instead. When you run tprbuilder vebose, it runs a different linker command (w/o the tigcc library) than when running with tigcc. I tried to compile it on a Sparc machine (Solaris 2, not gentoo), and the binaries didn't work. I was using gcc 3.2.2. I don't know if this will affect gentoo sparc, but it would be nice to know if someone has a gentoo sparc machine who might test this...
This is what I get when I call tprbuilder: tprbuilder -v Windows.tpr tprbuilder: tigcc Windows.c -o "Windows" -n Windows -Os -Wall -W -Wwrite-strings -WA,-k,-g,-t --optimize-nops --optimize-returns --optimize-branches --optimize-moves --optimize-tests --optimize-calcs --remove-unused --flash-os -DKERNEL_FORMAT_BSS -DKERNEL_FORMAT_DATA_VAR --verbose tigcc: /usr/ti-linux-gnu/bin/gcc -Os -Wall -W -Wwrite-strings -DKERNEL_FORMAT_BSS -DKERNEL_FORMAT_DATA_VAR -B/usr/ti-linux-gnu/bin/ -I/usr/ti-linux-gnu/include/c Windows.c -S -DFLASH_OS -o Windows.s tigcc: /usr/ti-linux-gnu/bin/patcher Windows.s -o Windows.s tigcc: /usr/ti-linux-gnu/bin/as -mc68000 -I/usr/ti-linux-gnu/include/s Windows.s -o Windows.o --keep-locals tigcc: /usr/ti-linux-gnu/bin/ld-tigcc -n Windows --optimize-nops --optimize-returns --optimize-branches --optimize-moves --optimize-tests --optimize-calcs --remove-unused --flash-os --verbose Windows.o /usr/ti-linux-gnu/lib/flashos.a -o Windows Warning: Flash OS support in TIGCC is experimental. Warning: Unresolved global import `__startup_code'. Warning: Unresolved global import `__kernel_format_data_var'. Warning: Unresolved global import `__nostub'. Warning: Unresolved global import `__kernel_format_bss'. Warning: Unresolved global import `__kernel_format_rom_calls'. Warning: Unresolved global import `__set_file_in_use_bit'. Error: Support for `.??u' files is not implemented yet. Use `--outputbin'. Everything seems to be fine, but it won't link.
Right. There should be a $TIGCC/lib/tigcc.a argument to the ld-tigcc call, but it's not there. Take a look at the difference b/w tprbuilder -v Hello\ World\ 1.tpr and tigcc -v Hello\ World\ 1.c
Oh, now I get it. You're right, if I add this to the linker's call it get built. I'll ask the tigcc team, let's see what they have to say to this. Meanwhile I will update the ebuild to install flashos.a and fargo.a too.
Created an attachment (id=32052) [edit] new ebuild, installs flashos.a and fargo.a new ebuild, installs flashos.a and fargo.a requires a68k-fix.patch
Created an attachment (id=32486) [edit] fixes a tprbuilder bug
Created an attachment (id=32487) [edit] new ebuild, needs a68k-fix and tprbuilder-fix http://p080.ezboard.com/ftichessteamhqfrm5.showMessage?topicID=2642.topic I talked to the tigcc team, the tprbuilder bug will be fixed in the upcoming release. Meanwhile, I made a little patch to fix it. BTW: If anyone has -O3 in his CFLAGS (and gcc 3.4.0 perhaps), please compile all the examples and tell me if you get segmentation faults.
This new ebuild with the tprbuilder patch works perfectly now for me... I use x86, gcc 3.3.2, and -O2. So I don't know about segfaults... I don't get any...
Created an attachment (id=32881) [edit] ebuild for 0.95_beta8-r1 version bump: 0.95_beta8-r1 released. I mirrored this at Angelfire, I don't know whether they allow unlimited traffic. Changes to the ebuild are minimal, it still requires a68k-fix and tprbuilder-fix.
A few comments from the maintainer of TIGCC/*nix for the TIGCC team: * First of all, a new release (0.95 Beta 10 r1) is out. * You definitely shouldn't use Binutils 2.14.90.x.x, those are not GNU releases, but H.J.Lu's "Linux Binutils" releases, which are CVS snapshots which a few patches and which he explicitly notes are intended to be used only for Linux-hosted Linux-targeted compilation. And anyway, I'd recommend against using ANY Binutils release other than the one I did the patch against, it may or may not work, and it might even break in subtle ways. * What's that A68k fix for? Wouldn't it make sense for me to fix this for all platforms if you are fixing a real issue?
Just to tell anyone what I told Kevin: * I'll wait for 0.95_beta10-r2, as there are some files missing in the package. * This ebuild uses binutils 2.14 as long as anyone convinces me to use another version *and* modifies the tigcc patch or if tigcc requires another version. * a68k-fix.patch comments out some 'external' declarations which are already made in /usr/include/fcntl.h. I don't know whether this appears on other platforms too...
Created an attachment (id=33188) [edit] ebuild for 0.95_beta10-r1 <WARNING>Don't fetch 0.95_beta10-r1's sources from tigcc.ticalc.org, a file is missing in this tarball. I repacked this version with reorder.c file Kevin sent me and put it on my Angelfire account.</WARNING> Version bump: 0.95_beta10-r1 tprbuilder-fix.patch is not needed anymore, a68k-fix.patch is still required.
Version bump: 0.95_beta10-r2 Just rename the ebuild for 0.95_beta10-r1.
Version bump (0.95_beta11-r1) rename the ebuild accordingly and change the line epatch ${S}/sources/gcc/gcc-${BASE_GCC}-tigcc-2.diff to epatch ${S}/sources/gcc/gcc-${BASE_GCC}-tigcc-3.diff builds fine here. BTW: Does somebody think about putting this in portage? If not, I'll volunteer as maintainer for this package... (if I get dev access of course ;-)
Created an attachment (id=38360) [edit] tigcc-0.95_beta16-r1.ebuild I wanted to test tigcc for my TI92+ and was happy to find it already in portage. Nevertheless I had to do some changes, so I'm attaching an ebuild for the current version. Compiled fine on x86, compiled code works on my TI92+. Only the html-docs gave some errors.
Created an attachment (id=40267) [edit] tigcc-0.95_beta17-r1.ebuild
Lars if you want to commit this go ahead. tigcc-0.95_beta19-r1 has been released. If you can get the ebuild to refer to a version number like Roberts it would be good. The file isn't in that location yet though.
Created an attachment (id=40284) [edit] tigcc-0.95_beta19-r1.ebuild
Thanks robert - commited (finally) were you going to add a /etc/env.d/gcc file or not? Any problems let me know. Lars can I please encourge you to go dual maintaince on this one. You seem to be using it.
No I was not going to add such a file, as gcc and tigcc can happily coexist. BTW I tested this on amd64 and it seems to work fine... IMO it's safe to add ~amd64.
amd64 person, can you confirm this.
can confirm that, added ~amd64 keyword in CVS
tigcc 0.95_beta20-r1 is out. Yet another case of RE US (rename ebuild, upload sources), it builds fine with the build in portage.
tigcc-0.95 Final is out. see last comment
version 0.95-r2 added. Please do a new bug report for a version bump. I almost forgot about this one. Hope it works cause I haven't tested it that much.
