I've been trying to get tigcc/ktigcc and tiemu installed all day, but can't get anything to work. I found some precompiled binaries on the tigcc website and they seem to work (spits out a .89y file), but i can't actually test as i can't get TiEmu running (it complains about some kde libs, i think my version is too new?) and the same with ktigcc. Does anyone currently have either running on their Linux distro? Thanks

* TILP and TIEmu can be compiled with http://lpg.ticalc.org/prj_tilp/download/install_tilp.sh and http://lpg.ticalc.org/prj_tiemu/downloads/install_tiemu.sh . The KDE 3 integration is disabled by default (it hardly brings anything), but the D-BUS integration is enabled. Be sure to look inside the files (especially install_tilp.sh) for lists of packages that you need to install before compilation can succeed

* the procedure to compile GCC4TI (feature superset, and bug subset, of TIGCC) from Git has been linked to by Jim. I'm aware that the two-phase build procedure, inherited from the unmaintained TIGCC, sucks - even if in GCC4TI, it has been made more streamlined, and more portable...

* the main reason to use KTIGCC is the easy to use (?), but highly peculiar and quite limited (not very powerful, I mean), build system that TIGCC Projects (TPRs) are. KTIGCC is a 1:1 port of the Delphi IDE, which doesn't fix its architectural flaws (e.g. wrt. building of TPRs, precisely). KTIGCC 1 depends on KDE 3.x, which modern distros don't package anymore, and KTIGCC 2 (based on KDE 4.x) is unfinished.
If you want to use KTIGCC (instead of, say, Makefiles calling into the base "tigcc" tool, like most toolchains - I can show you how to do that), you'll have to use KTIGCC 2.


Don't hesitate to ask for more questions

I think the offending cp in updatesrc is superfluous, I forgot to remove it when updating Install_step_3. In any case, it shouldn't be an error preventing from going forward

I have another version of tigcc.a from another tigcc source that i found to get the commandline assembler/linker running

It's OK in the short term, but older versions of tigcc.a contains more bugs (multiple crashers) and fewer optimizations, so you should use the files produced by step 3 (triggered internally by the build scripts)

the other files i've yet to look for

flashos.a is not important; pstarter.o is. But then again, the version of GCC4TI (which is going to be built by the scripts) is better than any version you can find on other sites.

I also get an error saying some files in a gcc directory are missing, but it went through that step successfully after again copying the files from the source from the site hosted on ticalc

The GCC and binutils tarballs are in the GCC4TI repository, no need to download them from anywhere else

but it still gives me kde errors (something about kde-config?).

When you do what exactly ?

I'll try again later today (maybe i'm downloading it incorrectly? I just download the .tar.gz file on the Downloads page).

Again, which downloads page (GCC4TI, TILP, TIEmu ?)

I think a lot of the TI libs are already installed from when i got tilemu running, i'll look into the two links you posted.

For both TILP and TIEmu, you really should replace your installs with fresh ones created by these scripts. These download from the most recent version possible.

I thought about posting over at yAronet, but i don't know how frequently people still stop by there

Activity has fallen in 2010 due to too much pollution in topics. Active TI-68k programmers, and ground-breaking Nspire development, have moved from yAronet and UTI to Omnimaga.

(nor did i want to ask such a basic question :p).

It's not such a basic question, actually

Thanks again!

You're welcome

I guess I'm going to retest the installation procedure by myself

EDIT: well, this particular step worked for me. And I should have checked your error message more carefully: GCC4TI doesn't reference $TIGCC/bin/gcc any longer, so the "tigcc" executable which gets invoked by Install_step_3 is not the appropriate one. I think that you left the existing TIGCC install in your PATH, and since Install_step_3 fails to protect itself from this situation (my fault), the build fails...
Please try the following procedure before restarting the compilation: in your temporary install directory (/tmp/gcc4ti-src, if you used the path indicated in INSTALL), edit scripts/Install_step_3 to replace (it should be line 46)
PATH="$PATH:$PREFIX_GCC4TI/bin"by
PATH="$PREFIX_GCC4TI/bin:$PATH"
And tell me if it fixes your problem. If it does, I'll commit the fix, crediting you for the report

Also, the arrow keys don't seem to work with the emulator (i have to press on the skin)

Indeed, they stopped working again on recent versions of GTK+ / X server / whatever.

I have edited my previous post about a minute after you posted, and then edited it further.
Before you erase the existing install of TIGCC, could you test the workaround I mention, which I hope will make the script more robust ? Thanks in advance

And don't worry, running the installation procedure didn't take me much time

Now this one is weird. The invocation of m68k-coff-tigcc-gcc must have succeeded, otherwise patcher wouldn't be called - but nowadays, GCC4TI's tigcc calls "tigcc-patcher".
What if you add
TIGCC="$PREFIX_GCC4TI" (with a space) in front of the three ${tigcc} invocations, several lines below the line you've just changed, in scripts/Install_step_3, and then restart scripts/Install again ?

If it does not fix the problem, remove your existing TIGCC install from the $PATH and unset the TIGCC environment variable, before launching scripts/Install. That's the situation which has worked for me earlier today - installing GCC4TI Git HEAD on a new computer which hadn't received GCC4TI before

Sorry for the trouble

Well, what worked ?
Did you just have to edit Install_step_3, or did you have to cleanup the existing TIGCC install ?

Under Linux, the IDE is called KTIGCC, and is just as bad, from an architectural POV, as the Delphi IDE. See post #2
If I had learnt earlier of the drawbacks of the TPR system (more precisely - if I had listened earlier to those who lamented about the drawbacks of that system), and its low scriptability, I wouldn't have converted several TICT programs from batch files to TPRs, and then had to work around the limitations when they struck me, one after another...
For trivial setups, TPRs does the job; however, for use cases as simple as compiling different files with different compilation options (e.g. time-consuming game logic with -O3 and UI with -Os), it falls apart.

I'm not too concerned about an ide, it's just as easy to make a little script to compile/send to the emulator for testing

There are multiple compile scripts in TICT programs, which could use a little bit of factorization to reduce copy&paste abuse on e.g. compiler and linker flags
There's a utility script for transferring a file to the emulator, I'll post it later.