MaxGUI Fltk Fedora 64bit problem
Archives Forums/Linux Discussion/MaxGUI Fltk Fedora 64bit problem
| ||
| Well I have to admit it this one has got me stumped. The libraries are there, but I get this error Compiling:Fl.cxx And I can't seem to nail it down. Any one have any ideas?/usr/lib/gcc/x86_64-redhat-linux/4.7.2/../../../../lib/crt1.o: In function `_start': (.text+0x18): undefined reference to `main' /tmp/ccW2Emjk.o: In function `Fl::wait(double)': Fl.cxx:(.text+0x61c): undefined reference to `fl_wait(double)' Fl.cxx:(.text+0x652): undefined reference to `fl_wait(double)' /tmp/ccW2Emjk.o: In function `Fl::ready()': --- And lot more --- And Fedora is pant's too boot. |
| ||
| Well, main() is in the appstub module, which kind of implies your build is not building correctly, because a module build shouldn't link to crt :-p Perhaps fltk has bigger issues with that version of the compiler. |
| ||
| Perhaps fltk has bigger issues with that version of the compiler. I'm starting to think the same thing or there are some issues with the default build environment in the 64bit version of fedora. |
| ||
| Solution: Install Ubuntu |
| ||
| Solution: Install Ubuntu Why would I want to install that pile of crap when Linux Mint is better. |
| ||
| Why would I want to install that pile of crap when Linux Mint is better. :P the real solution is to delete the maxgui.mod and install wxmax. |
| ||
| @Captain: If there is a problem you just move away instead of trying to solve it? It may be a problem with FLTK but it also is able to bug out other parts so it is better to narrow down the problem - else you end up running into trouble in later stages. @dawlane / "mint is better": Hope you talk about the debian-version (think you stated that in another thread), else you get a *buntu-based distro (which I use now but with the XFCE-flavour) bye Ron |
| ||
| For the compiler problem. I've come across a few ( and I do mean less than 8 ) forums posts about this issue for fltk ranging from the building and linking order of the static library to running fltk-config to get compiler/linker flags. I doubt that there are any fedora gurus around here and asking around the fedora forums would be a problem with blitz max being licensed software. Is there some licensing/coding issue as to why fltk in the fltkgui module is built from the fltk source inside and statically linked instead of just dynamically linking to libfltk.so? The version of fltk across the Linux distributions all seem to be using version 1.3.0 (with bug fixes). I did read something about 32bit support not being implemented by default (or design) in fedora. Maybe that's possibly why you don't see anything 32bit related in the wonderful (being sarcastic here) package manager. Even adding repositories for 32bit appears to be a black art ( weird scripting macros and no useful information that's current on how it works ). Maybe I should just draw a pentagram, light a few candles and sacrifice a few virgins ( or the fedora developers who obviously are virgins ) with the bonus of my soul and get one of the demons of hell to solve the problem. Some how I think my soul will be safe by the looks of it. And at least on the bright side they'll be one less Linux developer team in the mix. the real solution is to delete the maxgui.mod and install wxmax. And the point of this would be what?I'm trying to get the default install of Bliztmax to work across all of the main free distributions ( Debian/Ubuntu/Mint/openSUSE/Fedora ). So that I can write one install script that does the lot for both 32bit and 64bit. If BlitzMax cannot work across all the main distributions as it stands then it kind of defeats the objective. I have said many times before that there is "NO STANDARD" between many of the distributions and this is what makes people get pissed off with the whole Linux affair and the main reason why Linux isn't one of the top desktop operating, because people who have heard of it will still see it as an operating system for computer geeks. Even getting the operating system information like version and name requires a feat of scripting prowess as many distributors haven't implemented lsb_release. You can install that package for fedora and others, but it kind of defeats the whole point of it. Plus many developers and hardware vendors have to walk a legal minefield with the licensing issues. @Derron: Everything else that's in the standard BlitzMax148_linuxx86 archive works. It's just having major issues with fltk. The problem must have something to do with the default build environment as there is only one gcc-c++ package in there for 64bit and any .i686 development package installed for glibc etc looks to be limited. Actually the debian version of Mint has a tendency to break every so often. It's not something I would recommend for use. Unless you like.. 1) D.I.Y. 2) Tell them and go on holiday for a week or so until hopefully they've fixed it. |
| ||
| and this is what makes people get pissed off with the whole Linux affair Personally, I feel that if you want to write software on a particular OS, you need to understand how it works, where to find things, and how to set everything up to enable you to build your stuff. FLTK - Fun fun fun :-) |
| ||
| Personally, I feel that if you want to write software on a particular OS, you need to understand how it works, where to find things, and how to set everything up to enable you to build your stuff. That's the problem with Linux distributions. For one thing there's no standard naming for packages across the distributions and some distributions require you to jump through hoops to get things to work like 32bit support on 64bit machines. And if your going to use something like BlitzMax and you new to Linux or like some who hasn't got the patience and says things like "None of this works. Is there a version of Linux that actually works?". I think you can see my point. |
| ||
| The latest debian 64 bit wasn't too hard.. I had to force in a couple of packages and then build a dummy 32bit package aswell to satisfy apt-get's dependencies. It just wouldn't install besides the 64 bit package, and that package was only needed to satisfy the dependencies on the forced packages... |
| ||
| @Sub_Zero: Why do such messing around when all I did was this for version 7? I haven't figured out why the build environment doesn't work on the 64bit version of Fedora. It looks like for some reason that when the object file is built in the temp directory isn't having trouble linking the references that to the other bmx part of fltk module. |
| ||
| Well booted up Fedora this morning removed gcc/g++, installed some updates then tested out a new install script. And would you believe it the bloody thing compiled all the modules without incident. There for I have come to two conclusions. 1) When I was testing packages. I broke gcc somehow. 2) The update solve the problem. |
   |