gcc 3.4
Archives Forums/Linux Discussion/gcc 3.4
| ||
| finally got round to grabbing the latest blitzmax build for gnu/linux (havn't done any blitz coding for months, sorry!), but it seems the compilers not happy with my version of gcc - 3.4.5 to be precise. the output console shows blitz is expecting 3.3, and as such returns a command not found during the build - doh! any way i can tell blitz i'm using another gcc version? some config/source file to edit maybe? cheers. |
| ||
| I think it just calls gcc with the arguments of the source files. Maybe your gcc isn't located in the right directory? |
| ||
| From what I understand a symbolic link will fix it. Generally the Linux discussion Forum should be your first port of call for Linux related enquiries, where this particular thread seems to offer a solution as far as I can tell. |
| ||
| now why didn't i think of that?! <grin> my development box isn't booted up right now, but i'll stick a symlink down as soon as i do - should work a treat, cheers. |
| ||
| hmm, seems symlinks don't work - is this a compatibility issue with amd64? blitz complains of both gcc and g++ not being found, but looking in my /usr/bin i already have a couple of symlinks with version references in there file names, and thus i created another 2 (see below code) with the version references blitz is assuming, pointing to the same locations: trickyric@localhost /usr/bin $ su Password: localhost bin # ln -s /usr/x86_64-pc-linux-gnu/gcc-bin/3.4.5/x86_64-pc-linux-gnu-gcc ./gcc-3.3 localhost bin # ln -s /usr/x86_64-pc-linux-gnu/gcc-bin/3.4.5/x86_64-pc-linux-gnu-g++ ./g++-3.3 but now when i try to build from blitz i get the below output during the linking stage: /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/X11R6/lib/libGL.so when searching for -lGL /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libGL.so when searching for -lGL /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/X11R6/lib/libGLU.so when searching for -lGLU /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/X11R6/lib/libGLU.a when searching for -lGLU /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libGLU.so when searching for -lGLU /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libGLU.a when searching for -lGLU /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.5/../../../libGLU.so when searching for -lGLU /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.5/../../../libGLU.a when searching for -lGLU /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libGLU.so when searching for -lGLU /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: skipping incompatible /usr/lib/libGLU.a when searching for -lGLU /usr/lib/gcc/x86_64-pc-linux-gnu/3.4.5/../../../../x86_64-pc-linux-gnu/bin/ld: cannot find -lGLU collect2: ld returned 1 exit status similarly, if i simply symlink to g++ and gcc respectively, instead of the above output i get a single: gcc-config error: Could not run/locate "g++-3.3" even after an env-update. for the record i do not remember the builddb command for updating the locate/slocate database, but from memory i seem to recall this was depricated in gentoo a while back as env-update does a similar job? any ideas? cheers. |
| ||
| I think the 64bit linux version problems were floating around already. Searching for them should give you a hint on what might solve or not solve the problem. |
| ||
| You need to install gcc3.3 and 32 bit legacy development libraries. It is most likely possibly although it would be far far far simpler for you to install Ubuntu32 or similar until we start supporting a Linux64 based BlitzMax distribution. In regards to Linux in general the other big problem is not installing 3.3 with some symlink trickery. 3.4/4.0 based Linux systems because of the major changes to the C++ ABI are not binary compatible with gcc3.3 based systems so any binaries you produce if you do manage to install compatible 32 bit libs on your system will still not be compatible with most other Linux systems. |
| ||
| cheers. seems i'm stuck for now then :-(. i purpose built this system and purpose chose gentoo for x86_64, so switching or dual booting to/with a 32bit alternative simply isn't feasible. whats more, if my softwares are not compatible with most other systems then my role as a developer doesn't stand. when i switched from windows development to gnu/linux development, i anxiously waited for the blitzmax release for its cross platform compatibility, and thus if this compatibility is lost at any level, my primary love of blitzmax is lost. for now i'll just stick with c++ and the qt framework, and begin another anxious wait for blitzmax to support the 3.4 libs hehe. its been a while since my blitzmax days anyway, yet alone my blitz days in general, so a little while longer won't hurt. must admit though, some of the latest screenshot postings make for some jealous drooling when you can't compile your own workings, lol. cheers anyway. |
| ||
| I`ve had the same gcc problem since upgrading from BMax 1.09 (SuSE 9.3 Pro), I logged in as root, copied the /usr/bin gcc icon, pasted it somewhere else changed its name, copied and pasted it back. Repeated it so I had both g++ and gcc-3.3 and now its ok. |
| ||
| so basically you copied the actual binary under a different name, so as blitz assumed it had found the 'right' version? technically this is exactly the same as a symlink (symlinks are pseudo files that redirect to actual files, so when you call a symlink your actually calling the binary (or whatever) that the symlink refers to - thus by creating a symlink of gcc-3.3 and pointing it to gcc, your actually doing the same as copying gcc and renaming it to gcc-3.3, only your saving a huge amount of disk space in the process). unfortunately this is what isn't working for me, and the above posts suggest this is largely due to my use of a 64bit kernel, binaries, and libraries. cheers anyway. |
   |