debrouxl / gcc4ti Goto Github PK

When Multiple IDE's are opened They always appear on the main taskbar in windows 10 despite being moved to another monitor.

The FSF address in the license files is no longer correct; see a copy of the GPLv2 license for the new address, which is now:

51 Franklin Street, Fifth Floor, Boston, MA  02110-1301, USA

Commit 56510f7 removes a macro from your fork of TIGCCLIB, breaking source compatibility. Functions and macros in TIGCCLIB can only be deprecated, never removed. And in this case, if you think the macro is not good enough, the proper fix is to replace it with a function that works more reliably, but most definitely not to just remove it.

When compiling, I am unable to include local files using the include "file.h" syntax. This is even with the -I. GCC switch. The compiler always errors with "No such file or directory." I am able to compile when providing GCC with the absolute path. This leads me to believe that GCC4TI does not use the current project as the working directory (a clear error).

After running scripts/Install, tigcc itself seems to build just fine, but it errors with Error executing /usr/local/share/gcc4ti/bin/m68k-coff-tigcc-gcc and the installation fails. The only binaries in gcc4ti/bin at that point are a68k, ar-tigcc, envreg, ld-tigcc, tigcc, tigcc-patcher, tprbulider

Parts of your forks still attempt to impersonate TIGCC, confusing users. Both your version of "TIGCCLIB" and of "ld-tigcc" are modified (including some changes which have most definitely not been approved by the TIGCC Team). Therefore, it is not appropriate to call them "TIGCCLIB" and "ld-tigcc". Please call them "GCC4TILIB" and "ld-gcc4ti" or come up with some other name for them. Your unauthorized use of the "TIGCC" name for your forks and the nature of the changes they contain hurt the reputation of the TIGCC Project. Lack of time is not a fair excuse, because you have had years to do the renames (and they should have been done before making any releases of your fork).

On HW3, GrayGetSwitchCount seems to not work, or simply never return a different value. Functions such as GrayWaitNSwitches and GrayDBufToggleSync seem to freeze when run on tiemu as well as on actual hardware. I am using tigcc version 1.3.4 built for TIGCC/*nix version 0.96 Beta 11 r1.

Since TiEmu Straight up refuses to work on Windows 10 it would be nice to have this option back. (I tested VTI and it works perfectly fine.)

I just spent the last two hours trying to configure wine to run UpdateInclude.exe to no avail. Any advice and/or patches to make the process work would be wonderful.

On a related note, I have some patches for the docs but will not submit them until I can test them.

On arch linux with gcc 12.2.0, I am attempting to create a PKGBUILD so that I can put gcc4ti on the AUR. Running the installation script manually, I am able to install the software using a custom prefix. I am having problems executing the (slightly modified) install script from inside of the build function in my PKGBUILD. Here is the relevant bash function:

build(){
        cd "$pkgname/trunk/tigcc-linux/scripts"
        ./updatesrc
        ./package_src
        cd ../gcc4ti-0.96b11/scripts
        cp ../../../../../../Install.sh .
        PREFIX_GCC4TI="$(realpath installation)" ./Install.sh
}

The function navigates to trunk/tigcc-linux/scripts and executes updatescr and package_src as instructed. Then it navigates to trunk/tigcc-linux/gcc4ti-0.96b11/scripts. It copies my modified installation script (in which I've copied the original installation script and only removed the input prompts) into the scripts directory. It runs the install script with a prefix indicating a directory in the scripts directory - so it should install tigcc to trunk/tigcc-linux/gcc4ti-0.96b11/scripts/installation.

When running the build function, binutils compiles, but gcc fails to compile. The error is:
fatal error: gtype-desc.h: No such file or directory
After manually adding this file and trying again, I've seen that many more files are missing. The compilation succeeds, however, if inside of the build function I run the install script with sudo, so I suspect it's a permissions problem. Note that I don't need to use sudo to manually use the installation script.

Unfortunately, since I don't know enough about makepkg, I can't give the exact conditions required to reproduce this issue. Is there any reason why the install script should stop working inside of my build function, or when run from makepkg in general?

It looks like there's a problem building the old version of gcc with gcc 9.1+, currently the version in Fedora Rawhide:

../../../download/gcc.ti/gcc/pretty-print.h: At top level:
../../../download/gcc.ti/gcc/pretty-print.h:310:6: error: 'cgraph_node' is not defined as a type
  310 |      ATTRIBUTE_GCC_PPDIAG(2,3);
      |      ^~~~~~~~~~~~~~~~~~~~
../../../download/gcc.ti/gcc/pretty-print.h:313:6: error: 'cgraph_node' is not defined as a type
  313 |      ATTRIBUTE_GCC_PPDIAG(2,3);
      |      ^~~~~~~~~~~~~~~~~~~~

This was reported upstream here.

As indicated in the README, errors concerning cp should be reported.
I get this while running updatesrc :

cp: impossible d'évaluer « ../../tigcc/archive/tigcc.a »: Aucun fichier ou dossier de ce type
cp: impossible d'évaluer « ../../tigcc/archive/flashos.a »: Aucun fichier ou dossier de ce type
cp: impossible d'évaluer « ../../tigcc/starters/build/pstarter.o »: Aucun fichier ou dossier de ce type

Those 3 files does not exist.

Commit 4b9c4b5 breaks backwards compatibility!
Minimal test case:

#define USE_TI89
#include <float.h>

void _main(void)
{
}

This compiles with the real TIGCC, but will produce a "No target calculators specified" error after the above commit.

One of the basic principles of TIGCCLIB is that all headers include <default.h>, so that users can rely on the fact that including any TIGCCLIB header is enough to apply options, without having to check on a case-to-case basis whether that actually holds for any particular header. So Lionel's commit is totally user-unfriendly, in addition to being incompatible. But even just the incompatibility would render it unacceptable.