1. both gcc and psp-gcc read env CPATH/C_INCLUDE_PATH/CPLUS_INCLUDE_PATH/LIBRARY_PATH as header/lib search path, so that if we define them, gcc or psp-gcc might include/link files from wrong place.
I think it's better to change the env name in psp-gcc, just like add prefix "PSP_" or such on.
2. full gcc package includes java/fortran/testsuites and some other things with no use, we could have only gcc-core and gcc-g++ downloaded to save diskspace and decompress time while building.
suggestions to psptoolchain
Here's my patch, for gcc 4.2.2, tested to work fine.
http://www.aeolusc.com/down/gcc-4.2.2-PSP.patch.bz2
1. Get env PSP_CPATH/PSP_C_INCLUDE_PATH/PSP_CPLUS_INCLUDE_PATH/PSP_LIBRARY_PATH for headers/libs search
2. Update gcc/g++ to 4.2.2
http://www.aeolusc.com/down/gcc-4.2.2-PSP.patch.bz2
1. Get env PSP_CPATH/PSP_C_INCLUDE_PATH/PSP_CPLUS_INCLUDE_PATH/PSP_LIBRARY_PATH for headers/libs search
2. Update gcc/g++ to 4.2.2
I don't think CPATH/etc should be changed. I've never seen a cross compiler do that before, and it seems that it will only add to incompatibilities and confusion when you try to cross-compile something. For example, build systems designed to handle cross compilers but expect things like CPATH to still work as documented will be broken.
As far as gcc 4.2.2, what has changed? Are there any non-x86 features that even matter for us?
As far as gcc 4.2.2, what has changed? Are there any non-x86 features that even matter for us?
no, i think leave them unchanged would cause incompatibilities and confusion.
example:
Compiled and installed pspsdk to /usr/local/pspdev(yes, that's default path).
Move the pspdev to another place without compile it again(e.g. move to /usr/pspdev), add /usr/pspdev/bin to PATH, works fine for c files.
But if compile cpp files with libstdc++ headers, you will get error "headers not found", so we should set up env CPLUS_INCLUDE_PATH to /usr/pspdev/psp/include.
then confusion comes around, compile with normal g++, it also search /usr/pspdev/include first, whatta hell...
example:
Compiled and installed pspsdk to /usr/local/pspdev(yes, that's default path).
Move the pspdev to another place without compile it again(e.g. move to /usr/pspdev), add /usr/pspdev/bin to PATH, works fine for c files.
But if compile cpp files with libstdc++ headers, you will get error "headers not found", so we should set up env CPLUS_INCLUDE_PATH to /usr/pspdev/psp/include.
then confusion comes around, compile with normal g++, it also search /usr/pspdev/include first, whatta hell...
They can both cause confusion. Cross compiling is tricky. I think sticking with the way every other gcc-based cross compiler has ever worked is a far more reasonable solution.aeolusc wrote:no, i think leave them unchanged would cause incompatibilities and confusion.
This is not a practical example. When you move a GCC installation away from its prefix, you'll run into a lot more problems than just the CPLUS_INCLUDE_PATH. For example things like "psp-gcc -print-libgcc-file-name" hold a hardcoded path. You might get away with the "-B" option or setting GCC_EXEC_PREFIX, but rebuilding with the proper path is really the right way to move it.example:
Compiled and installed pspsdk to /usr/local/pspdev(yes, that's default path).
Move the pspdev to another place without compile it again(e.g. move to /usr/pspdev), add /usr/pspdev/bin to PATH, works fine for c files.
But if compile cpp files with libstdc++ headers, you will get error "headers not found", so we should set up env CPLUS_INCLUDE_PATH to /usr/pspdev/psp/include.
Yes, and if you set CFLAGS in your environment, then they'll apply to both compilers. That's what happens when cross compiling things -- you need to set up your environment properly for which system you're building for. Or are you also proposing that we also rename CFLAGS->PSP_CFLAGS, LDFLAGS->PSP_LDFLAGS, etc? By your argument we should, but it should hopefully be clear how wrong that would be.then confusion comes around, compile with normal g++, it also search /usr/pspdev/include first, whatta hell...
Builds fine, or works fine on the PSP too? Please, test some non-trivial programs, there are a lot of details that go into how binary loading works on the PSP under various firmwares and loaders and it would be good to verify that various assumptions are still valid.aeolusc wrote:tested to build pspsdk, some 3rd part libs, works fine.
Bigger? How much?to jimparis: elf's generated by psp-gcc 4.2.2 have diffenrent size from ones by psp-gcc 4.1.0, so obviously some changes are made to mips compiling/linking
I think upgrading to gcc 4.2 is a good idea, but a lot of people rely on it so it's worth taking some extra time to verify things. For the gcc-4.0.2 to gcc-4.1.0 upgrade, we left both in the toolchain for over a year before switching to 4.1.0 as a default. (not suggesting we wait that long, just as a reference)