BlitzMax problems with SuSe9.1
Archives Forums/Linux Discussion/BlitzMax problems with SuSe9.1
| ||
hi i bought BMax 5 days before and now i tried it for the first time. i got an error message " sh: line 1: g++ : command not found Build error: Failed to link /home/justfreeman/Coden/BlitzMaxBeta101/test process complete i hope somebody is able to help me. |
| ||
You must install GCC. |
| ||
i think GCC is installed, do i need special version of gcc? |
| ||
You don't need a special version, but you should have at least v2.95 or v3.3 of GCC. You can check by opening up an terminal window and typing 'gcc -v'. If it works, then check the linker by typing 'ld -v' at the command line. If one of them doesn't work, reinstall GCC. |
| ||
More spesific you need the RPM for c++ support in gcc: gcc-c++-3.X.X-XX.i586.rpm.. (XX = something... Latest is 3.3.3-41) That's the one that provides the g++ binary.. |
| ||
justfreeman@linux:~> gcc -v Reading specs from /usr/lib/gcc-lib/i586-suse-linux/3.3.3/specs Configured with: ../configure --enable-threads=posix --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --enable-languages=c,c++,f77,objc,java,ada --disable-checking --libdir=/usr/lib --enable-libgcj --with-gxx-include-dir=/usr/include/g++ --with-slibdir=/lib --with-system-zlib --enable-shared --enable-__cxa_atexit i586-suse-linux Thread model: posix gcc version 3.3.3 (SuSE Linux) justfreeman@linux:~> ld -v GNU ld version 2.15.90.0.1.1 20040303 (SuSE Linux) i think everything is ok, but it doesn't work... please help |
| ||
Open up a console, type g++ and let us know what happens. |
| ||
when i type g++ in a console, i get an error message.. bash: g++: command not found i'm sorry for the double-post |
| ||
which means you need to install g++, I haven't got experience with Suse but I'd be suprised if there isn't some friendly package manager that lists the C++ / G++ packages in a developer tools section so you can install them easily from the distro disks |
| ||
As I said: gcc-c++-3.3.3-XX.i586.rpm (XX = something... Latest is 41) Install this and it works.. |
| ||
ok i installed gcc-c++-3.3.3.41.i586.rpm, then type g++ in the console justfreeman@linux:~> g++ g++: no input files then i tried to compile Print "test" waitkey then Building untitled1 Compiling:untitled1.bmx flat assembler version 1.52 3 passes, 3662 bytes. Linking:untitled1.debug /usr/lib/gcc-lib/i586-suse-linux/3.3.3/../../../../i586-suse-linux/bin/ld: cannot find -lGLU collect2: ld returned 1 exit status Build Error: Failed to link /home/justfreeman/special/BlitzMax/tmp/untitled1.debug Process complete |
| ||
Now it is some kind of Gl-devel rpm missing.. On my Mandrake 10.1 it was libMesaGLU1-devel OR libMesaglut3-devel.. Not sure witch one.... |
| ||
ok, i installed both now i get new error ...sorry Building untitled1 Compiling:untitled1.bmx flat assembler version 1.52 3 passes, 3662 bytes. Linking:untitled1.debug /usr/lib/gcc-lib/i586-suse-linux/3.3.3/../../../../i586-suse-linux/bin/ld: cannot find -lcomdlg32 collect2: ld returned 1 exit status Build Error: Failed to link /home/justfreeman/special/BlitzMax/tmp/untitled1.debug Process complete |
| ||
?? comdlg32?? Never seen/heard of it.. To me it sounds like some windows thingy.. Sorry.. I also did a search on http://www.rpmfind.net , and nothing came up.. (Great site for finding rpm things btw...) |
| ||
i serched for comdlg32 and i found it . these file is part of Wine.....k, i try to fix the probem. Is there a distribution,which have no problems with BlitzMax? |
| ||
Well I'm using Mandrake 10.1, and the only thing I had to install "extra" was the GL stuff.. But some others reported that there was trouble with bmax so.. I think it boils down to what's installed & type of gfc-card/driver and so on.. When it comes to your setup, and wine..... I don't get it.. I've never installed anything wine like on my Linux-box... B-Max don't need it as far as I know. When that's said, my box is pretty much out of the "box",ie didn't change anything drastic.. Only thing I've done is install the official nvidia driver. Everything else is from the cd's/update site.. |
| ||
MU, There is no way it should be trying to link with comdlg32, I would try and rebuild your modules again (rebuild modules without quick build). If you are still getting it I would blame what ever you did to install the GL libraries, what exactly did you do? |
| ||
@skidracer: And then I have a question.. Why is everyone talking about rebuilding the modules??? All I did was Sync modules, and it works.. Not that I've done any *big* kind of testing but.. Could you explain... *EDIT: Just for fun I now *did* try to rebuild modules.. And I get this error: Compiling blitz_app.c /mod/blitz.mod/brl.mod/blitz_app.c: In function 'bbReadStdin': /mod/blitz.mod/brl.mod/blitz.mod/blitz_appc:31: error: assignment of read-only location *UPDATE: the offending line: buf[1023]=0;if( p=strchr(buf,'\n') ) *p=0; changed to: buf[1023]=0;if( p=strchr(buf,'\n') ) p=0; And it works... At least I hope so.. |
| ||
Heh, I was just thinking that myself. The reason we are currently dependent on full gcc tools (and the reason perhaps i've been mistakenly thinking we should be supporting linux users rebuilding the modules) is that I thought linking would be different on each system, with the default G++ link options being a little intimidating to grasp / replicate to make linux blitzmax standalone. Thinking about it now, I think we should probably make an effort to try and come up with a distribution that is standalone like we are doing with win32/mingw with ld, libs and includes included in the BlitzMax directory tree. So yes, the solution for Mr FreeMan could be to resync the modules, DON'T try rebuilding them and see if you can get some samples to run. |
| ||
@Ole JR: Actually, you just need to change "const char *p" to "char *p" in blitz_app.c. (Edit: Yep it's 'p' not 'buf'. Wrong line) |
| ||
@Todd: ... ? There's no const char *buf in blitz_app.c, only const char *p.. But that's the one to change. ;-) (Found that in a thread *after* posting here..) @skidracer: I understand what you're saying. But it isn't required to rebuild modules for everyone is it?? Wouldn't a normal install be: Download, extract, sync modules & your done..?? And when compilation in b-max complains about some missing -I stuff then all there is to it, is getting the right devel-package..? Or like here g++ (or gcc-c++).. And no, I don't think you need the ld & stuff included with b-max.. Most distros comes with it anyway, and it isn't *that* hard to install if you missed it at systemsetup ;-) |
| ||
Unless your version of ld is incompatible with the version blitzmax seems to want to use :) like http://www.blitzbasic.com/Community/posts.php?topic=42276 that post by me :) |
| ||
@Specis: Or is this -> x86_64 the troble?? But I get your point... |
| ||
i dunno Ole JR, possibly it could be :) but as its compiling the modules perfectly i think it seriously is just an ld compatibility problem :) |
| ||
Ok.. Didn't know it compiled the modules... But at the same time I find it strange that it's the version of ld.. Considering people are running everything from ReadHat 9 to Fedora Core 3... There just have to be different versions out there.. If you do ld -v what do it say?? Mine is 2.15.92.0.2.20040927... |
| ||
Same [specis@localhost ~]$ ld --version GNU ld version 2.15.92.0.2 20040927 |
| ||
And mine is working so, what's left?? 32 vs 64...? |
| ||
seems that way, there must be differnces between the x86 and x86_64 toolsets, on a chance maybe my version of ld needs to run in one of its many emulation mode's or something :) im at a loss, but i suppose we could compair option lists from ld? |
| ||
And the list goes on... Eh.. It was a loong list of options there..! Maybe I found something of interest.. ld: supported targets: elf32-i386 a.out-i386-linux efi-app-ia32 elf32-big elf64-x86-64 elf64-little elf64-big srec symbolrec tekhex binary ihex trad-core ld: supported emulations: elf_i386 i386linux elf_x86_64 Supported demangler style: {none, auto, gnu, lucid, arm, hp, edg, gnu-v3, java gnat, compaq} All this and (much) more from ld --help But I don't think it help..... ;-) |