Linux - Failed to execute child process
Archives Forums/Linux Discussion/Linux - Failed to execute child process
| ||
| It has been long time since i have been using Linux and now i installed Xubuntu to test my project, but i can't get MaxIDE running... Last time i used Linux it worked fine. Here what is wrong when i try to execute:  |
| ||
| The error says MaxIDE doesn't exist in that location. I'd try copying that path and running it in Terminal. Then come back here if you get any different errors :-) |
| ||
| When i navigate with 'cd' to downloads directory and do this './MaxIDE' It tells me same thing and MaxIDE definetly exists and it's executable |
| ||
Try an ldd on it :ldd ./MaxIDE to make sure you have everything it needs. |
| ||
 |
| ||
| Heh... okay. Try "file" on it. Maybe you've installed the wrong thing :-) This is mine : $ file ./MaxIDE ./MaxIDE: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.27, BuildID[sha1]=0x4a7aa521b5b7df83c5731aca7bc63efc6389fba8, stripped May be worth extracting the package again, and see where you go from there. |
| ||
I extracted package many times. Here is my 'file'./MaxIDE: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[sha1]=81dd0a5e9a89a617923d3375b988261cd6b0dd0f, stripped Using BlitzMax 1.50 Here is also 'uname -a' Linux ari-Lenovo-G585 3.16.0-29-generic #39-Ubuntu SMP Mon Dec 15 22:27:29 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux |
| ||
| Okay, then you need to make sure you have all your 32-bit toys installed correctly. Since you are on 64-bit, you may not have the required 32-bit libs/binaries on your system. You may want to try the script in this post. It should get things installed that you will need to use and build 32-bit apps on your 64-bit system. |
| ||
| Script did what it did and i also have installed these packages. I posted them years ago when i had everything working. http://www.blitzbasic.com/Community/posts.php?topic=97050#1126877 |
| ||
| Hmm something is missing... Installing now... |
| ||
Installed these:gcc-multilib g++-multilib libxxf86vm-dev libglu1-mesa-dev libxft-dev x11proto-xext-dev And now i got this: ./MaxIDE ./MaxIDE: error while loading shared libraries: libX11.so.6: cannot open shared object file: No such file or directory |
| ||
| Cool. Now ldd should work and give you a full list of what you still have missing :-) You probably need at least : "libx11-6:i386" |
| ||
ldd ./MaxIDE linux-gate.so.1 => (0xf772b000) libX11.so.6 => not found libXxf86vm.so.1 => not found libGL.so.1 => not found libXft.so.2 => not found libXpm.so.4 => not found libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf761c000) libm.so.6 => /lib32/libm.so.6 (0xf75d6000) libgcc_s.so.1 => /usr/lib32/libgcc_s.so.1 (0xf75b8000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf759b000) libc.so.6 => /lib32/libc.so.6 (0xf73f0000) libdl.so.2 => /lib32/libdl.so.2 (0xf73ea000) /lib/ld-linux.so.2 (0xf772e000) libfontconfig.so.1 => not found I also did this, but still missing.. sudo ln -s /usr/lib/i386-linux-gnu/mesa/libGL.so.1 /usr/lib32/libGL.so sudo ln -s /usr/lib/i386-linux-gnu/libGLU.so.1 /usr/lib32/libGLU.so sudo ln -s /usr/lib/i386-linux-gnu/libX11.so.6 /usr/lib32/libX11.so sudo ln -s /usr/lib/i386-linux-gnu/libfreetype.so.6 /usr/lib32/libfreetype.so sudo ln -s /usr/lib/i386-linux-gnu/libXxf86vm.so.1 /usr/lib32/libXxf86vm.so sudo ln -s /usr/lib/i386-linux-gnu/libXft.so.2 /usr/lib32/libXft.so sudo ln -s /usr/lib/i386-linux-gnu/libXpm.so.4 /usr/lib32/libXpm.so |
| ||
| With libx-6:i386 ./MaxIDE ./MaxIDE: error while loading shared libraries: libXxf86vm.so.1: cannot open shared object file: No such file or directory ldd ./MaxIDE linux-gate.so.1 => (0xf775c000) libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xf75f7000) libXxf86vm.so.1 => not found libGL.so.1 => not found libXft.so.2 => not found libXpm.so.4 => not found libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7501000) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf74bb000) libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf749c000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf747f000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf72d1000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf72cc000) libfontconfig.so.1 => not found libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xf72a9000) /lib/ld-linux.so.2 (0xf775f000) libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xf72a5000) libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xf729e000) |
| ||
| I also did this, but still missing.. That's not going to work because you've given the wrong name to your symlinks. You've created a link called "libX11.so" but the app is linked to "libX11.so.6". You'll need them to have the same name. I'd try doing your symlinks again, but with the same filename as the source. And there's a fontconfig at the bottom you'll need too ;-) ... life is so much easier in 64-bit :-p The script doesn't appear to have done its job very well - I'd expect it to do all of this for you. |
| ||
linux-gate.so.1 => (0xf77c1000) libX11.so.6 => /usr/lib/i386-linux-gnu/libX11.so.6 (0xf765c000) libXxf86vm.so.1 => not found libGL.so.1 => not found libXft.so.2 => not found libXpm.so.4 => not found libstdc++.so.6 => /usr/lib32/libstdc++.so.6 (0xf7566000) libm.so.6 => /lib/i386-linux-gnu/libm.so.6 (0xf7520000) libgcc_s.so.1 => /lib/i386-linux-gnu/libgcc_s.so.1 (0xf7501000) libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xf74e4000) libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xf7336000) libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xf7331000) libfontconfig.so.1 => not found libxcb.so.1 => /usr/lib/i386-linux-gnu/libxcb.so.1 (0xf730e000) /lib/ld-linux.so.2 (0xf77c4000) libXau.so.6 => /usr/lib/i386-linux-gnu/libXau.so.6 (0xf730a000) libXdmcp.so.6 => /usr/lib/i386-linux-gnu/libXdmcp.so.6 (0xf7303000) and when i try to make symlink: ln: failed to create symbolic link ‘/usr/lib32/libXxf86vm.so’: File exists |
| ||
| This thread - which might as well be written in Chinese - is why I will never, ever understand the appeal of Linux! All this farting about just to get an IDE to work?? |
| ||
| When i first time installed MaxIDE to linux there was no problems what so ever... And i think i installed first time to Arch Linux. I am pretty much done with Ubuntu... |
| ||
Your link command should probably be this instead :sudo ln -s /usr/lib/i386-linux-gnu/libXxf86vm.so.1 /usr/lib32/libXxf86vm.so.1 Note that the filename matches the one that ldd says is missing... fun fun :-) |
| ||
| And still it's missing... |
| ||
| Yup... I am changing to Linux Mint 32 bit |
| ||
| All this farting about just to get an IDE to work? Not to put too fine a point on it, but no other piece of software I've encountered in the wild has this problem. BlitzMax has a lot of dependencies but neither bundles them, nor contains any way to communicate that fact to the OS: those are things you really need to do when packaging software. The Linux edition of BlitzMax is essentially just a binary blob released without an installer. It's not fair to put this problem on the Linux end. It works on 32-bit Linuxes more or less out of luck. |
| ||
| Brucey gave you the wrong link to the how to http://www.blitzbasic.com/Community/post.php?topic=101454&post=1235911 I should point out that I haven't tested this on the latest version of Ubuntu. There was a problem with getting BlitzMax to compile anything on the October release of Ubuntu and I never did bother to resolve the issue. |
| ||
| I think the big problem with last version is enabling of anti aliased fonts in MaxGUI/FLTK which introduces some dependency on some little known font directory lib which, an area where Linux is more flakey than audio (and by the looks, runner up to the honest and helpful notifications in many window managers). If I could travel back in time I would have gone with a curses based IDE as Linux windows managers in general continue in my humble opinion to be a complete joke. |
| ||
| an area where Linux is more flakey than audio Damn! I didn't know there was such a thing! |
| ||
| ...I would have gone with a curses based IDE... Yes please :-) |
| ||
Ok.. so i installed Linux Mint 32bit and now i got MaxIDE running, but when i compile i got this:Linking:test.mt /usr/bin/ld: /home/ari/Desktop/BlitzMax/mod/pub.mod/openal.mod/openal.release.mt.linux.x86.a(openal.c.release.mt.linux.x86.o): undefined reference to symbol 'dlopen@@...' //lib/i386-linux-gnu/libdl.so.2: error adding symbols: DSO missing from command line collect2: error: ld returned 1 exit status Build Error: Failed to link /home/ari/New Folder/test.mt Process complete I remember that i had this many years ago, but i can't remember what was wrong. |
| ||
| Ah.. nevermind. Just remembered to use 'Framework'. Why Windows is not needing this? |
| ||
| Yasha, the problem with binary distribution is a two edged sword in Linux. Native developers have no interest what so ever in reducing friction of anything not compiled from source and binary distributors haven't the know-how so no one has ever managed to come up with a standard. Also, every BlitzMax developer who produces a binary faces the exact same problem that Blitz Research does, yet has anyone stepped forward with a solution that isn't the basic shed load of shell script. |
| ||
| Alright.. Is there better way to find which modules i need than looking every one by one. For example, compiler needs module for 'Left' and i have no idea where that could be. |
| ||
Got it working, but something is still wrong. With Debug build i get:Unhandled Exception:Attempt to access field of method of Null object Without debugger it's just segmentation fault. Line what debugger is pointing is this: MidHandleImage(mcursor) and mcursor is this: Global mcursor:TImage = LoadImage("graphics/ui/cursor_menu.png")It's working with no problems Windows side. These modules are imported: Framework brl.Blitz Import BRL.Standardio Import BRL.Font Import BRL.GNet Import BRL.Max2D Import BRL.Audio Import BRL.Threads Import BRL.Math Import BRL.Random Import BRL.Glmax2d Import BRL.Stream Import BRL.System Import BRL.Timer Import BRL.httpstream Import BRL.polledinput Import BRL.keycodes Import BRL.reflection Import BRL.retro Import BRL.Graphics Going little bit offtopic, but hopefully i get my problems sorted out. |
| ||
| no one has ever managed to come up with a standard. Sure they have. On Debian-derived systems you can use dpkg or apt or their various frontends with binary-only software. e.g. Google does this for the closed-source release of Chrome. I assume you can do something similar with RPM-based systems (wouldn't know). This reduces your target platforms from "Linux" down to the specific distros you can maintain packages for, but that's not a bad thing (and probably won't substantially affect market size in practice). Anyway if this is a widespread problem as you suggest then a BlitzMax-oriented utility to ease the process wouldn't hurt. I'll go away and research that rather than complain, sorry. |
| ||
| Arska, in the BlitzMax debugger you should be able to see the value of mcursor. It is I think null, which means LoadImage failed which means you need to check your path name is correct and that file is present and previewable, then check you have got upper and lower case correct, (Windows doesn't care but Linux does). |
| ||
Nevermind on last one. PngLoader was missing. Now my project compiles. Thanks for everyone. Any ideas why FPS is like 50 % lower than Windows. (maybe it's just i have software overclock in use Windows side) Any things to remember when compiling to Linux? Edit: I am using currently my low-end laptop, so game is not poorly optimized. :D |
| ||
| @Yasha: I did knock up a tool written in bash script that allowed you to create a self extracting archive that when executed would attempt to detect the distribution and install the correct packages for that distribution. Of course any application installed this way could not be managed by any package manager and it would need to be told how to deal with any new distributions. I could send Mark an email and see if I can get him to adopt using it for deployment of BlitzMax for Linux. The real big problem with any Linux distribution is there is no standard naming conventions of packages. Though it is possible to use RPM to query the package database for a package name that contains a library by name, there is no such feature in apt unless you manually install apt-file. |
| ||
| Any ideas why FPS is like 50 % lower than Windows. Depending on your video card: A lot of the Linux video drivers are substandard, since many of the 'official' drivers are poorly written since they consider Linux an afterthought after their primary operating systems. and if you're using unofficial drivers they often depend on attempted reverse-engineering drivers from other platforms and trying to figure out the hard way what's happening under the hood, which may not (yet) take full benefit of your card's actual hardware capabilities. |
| ||
| I did knock up a tool written in bash script that allowed you to create a self extracting archive that when executed would attempt to detect the distribution and install the correct packages for that distribution. Of course any application installed this way could not be managed by any package manager and it would need to be told how to deal with any new distributions. My own POV above was rather the opposite: that one should be creating packages directly. Any distro you don't create a package for manually, you really can't honestly claim to support anyway, so there's no point trying to second-guess the existing process. Such tools should be for developers to create .debs and so on (where the requirement for something like apt-file is a non-issue since, well, developer needs developer tools), not as an aid to general distribution. At that point, since you know what went into it, there's no reason it shouldn't work just as well with the package manager as any native program. In the long run, I don't believe a tool that encourages Maxers to treat "Linux" as an OS target is helpful. It isn't one, and folks are always having to repeat that, so tools should reinforce it by being "for Debian", "for Ubuntu", etc. Potentially with "for experts" as the crossdistro escape hatch (with a lot of bundling), but as above, in practice my money says that isn't likely to be necessary (hell, in practice at the moment you have JoshK arguing that you shouldn't even use certain version numbers of Ubuntu if you want stability). Your tool would potentially be appropriate for deploying Max itself, although it still sounds like jumping straight to "for experts" when there are simpler options for the 99%. Not that I wish to criticize your awesome work, by the way. Thank you again for what you've provided and supported so far. |
| ||
| The "apt-get" way wont be available as long as "bcc" stays proprietary. I got this information when I got asked if my open source game could get added to some of the big repos. They then stopped because there is no way to freely compile the sources on your own (commercial compiler). So you will only be able to use "deb" etc as a form of "setup.exe". @50% fps Software GL will be much slower so there will be at least a running accelerated gl thingy. You could test your FPS differences by doing a simple test just drawing a single image as much as possible with flip ignoring vsync - so you might see if the differences are coming from the graphics or something in your source (an artificial delay, timer issues, ...). bye Ron |
| ||
| @Yasha: Using the distributions native package format would be the ideal solution. It is possible to deploy pre-built binaries using package managers without having to build directly from source. It does require knowledge of the package build system and a lot of information that you find tends to be focused on how to build packages for source code.The 1.50 version of bcc was built with Ubuntu 12.04 LTS, and as such will not work with Debian. As for JoshK arguing about not using certain versions of Ubuntu; he is right. Any one who has the mindset that the latest is the greatest is asking for problems. As at the moment there are two long term support versions, I would think that both would have to be supported, and clearly stated that support etc, is only for those versions. @Derron: You didn't mention what license your open source was using. If you released it under the GNU; then I would think that the license couldn't be up held in any legal issues that arise, as I'm sure that there is a clause in the GNU license that states that an end user has to be able to compile the code with easily free available compiler tool chain. I would consider looking at a license that should allow you to at least submit your application to the non-free repositories. |
| ||
| I am using zlib/libpng (but restricted commercial usage without former authorization). Even if this is normaly also a cause to NOT include it (they need to have allowed to use it commercially to add it to the "normal" repos ...which I never understood ... as long as nobody requests money for media containing the game ... they do not need to ask for an OK). Their main reason was the compiler thingy. Regarding "non-free" there is the problem of the building chain ... they cannot build the game out of the sources without the compiler. When providing a 32bit game only (binary) I do not know how they handle that (dependencies etc). Of course I would like to have more linuxers playing my game (currently I get about 6-700 downloads a month for each monthly full release - most of them are using windows, 2 or 3 on a mac and at least 2 linuxers - the download contains all binaries, so I do not have more exact stats). @packaging Will await what Yasha fiddles together ... having more options is always a better thing. If you do that in "blitzmax" it could even get integrated into maxIDE (deployment). Another option is "lua" as I thought about making things extendable in maxIDE (or another editor) via plugins (written in lua). If not for vanilla BlitzMax then maybe for the upcoming NG version of Brucey. bye Ron |
| ||
| Well if any one would like to have ago at creating .deb packages then here's a place to begin. You can find the tool I created here |
| ||
| The 1.50 version of bcc was built with Ubuntu 12.04 LTS, and as such will not work with Debian It actually can be made to work with Debian 7 (should be out-of-the-box on Debian 8) if you just force it hard enough... that's actually another idea I want to try to work in, since point-releases breaking things is another common gripe. Thanks for the pointers. This will be fun! |
| ||
| It actually can be made to work with Debian 7 (should be out-of-the-box on Debian 8) if you just force it hard enough... The only way without doing a hack of the binary is to use the same trick that's used for getting Steam up and running on Debian. |
| ||
| Heh, so the installer can't be written in BlitzMax. Is there a precedent for distributing an open source installer that installs and manages proprietry binaries? Maybe we can help ourselves to the tech nVidia use? |
| ||
| ttf-mscorefonts-installer is one of the most popular examples of such a thing. And yeah the "Steam trick" seemed to work for Max itself, although there are better options for new programs. |
| ||
| Heh, so the installer can't be written in BlitzMax There is nothing stopping anyone from writing an installer in BlitzMax. It's just that it will not run out of the box on all 64bit distributions, unless you install the 32bit dependencies or compile it with Brucey's bcc replacement. But then you would have to create two version, one 32bit and one 64bit. Is there a precedent for distributing an open source installer that installs and manages proprietry binaries? An installer is a program or script that just installs data, so any binary, images or text files are defined as data and are considered as separate works.http://www.gnu.org/licenses/gpl-faq.html#GPLCompatInstaller Maybe we can help ourselves to the tech nVidia use? I believe that the process used for the installation of propriety drivers by the likes of nVidia, uses a similar approach to the one I used. But I take it that they supplied a pre-compiled object files.I think that another topic or two should be created and made into sticky posts relating license and installation etc, instead of being discussed in an thread that started as something else. @Derron: You didn't mention what license your open source was using. If you released it under the GNU; then I would think that the license couldn't be up held in any legal issues that arise, as I'm sure that there is a clause in the GNU license that states that an end user has to be able to compile the code with easily free available compiler tool chain. The GPL bit of this statement isn't entirely correct. You should be able to release code that uses a propriety compiler as long as you give enough information on the name, version and where to get is as part of the source distribution. But for a standard repository, then it rings true. But the the information I found could be a little out of date http://www.softwarefreedom.org/resources/2008/compliance-guide.html |
| ||
| There is nothing stopping anyone from writing an installer in BlitzMax. It's just that it will not run out of the box on all 64bit distributions, unless you install the 32bit dependencies or compile it with Brucey's bcc replacement. But then you would have to create two version, one 32bit and one 64bit. You are missing my point. You can't really write Open Source code in BlitzMax because the compiler is not open source so for the installer to be valid open source it must be written in some other code. For the average Linux user with no money and not enough food to eat distributing proprietary software for Linux seems a pretty poor fit, especially if it exists simply for purpose of building more proprietary software. |
| ||
| So to fix the DSO error ya need to use Framework? I ask as this error is the main one I get when recompiling monkey, if I could compile it it would save me a load of coding etc. |
| ||
| You can cure the DSO errors by adding the library to the link process in the make file for Monkey and Import in BMax. |
| ||
| Well I added import "-Llibdl.so.2" to the source but the error remains |
| ||
| That's because you need to use -ldl and not the full library name. Using -L is for searching paths. http://ftp.gnu.org/pub/old-gnu/Manuals/ld-2.9.1/html_node/ld_3.html |
| ||
| well adding Import "-ldllibdl.so", Import "-ldllibdl", import "-ldllibdl.so.2" all fails to compile. In the end I just copied the binaries from a old monkey version and it works I dont know how well as it does seem to, all I want to do is look to getting a game working :) |
| ||
| Nono in order to import libdl.so according to this pattern, you write "-ldl". The "lib" and the ".so" are dropped. |
| ||
| So what is the command? |
| ||
| You needed to add -ldl to either the monkey template makefile LD_FLAGS or add it into #CC_OPTS. Import doesn't work that way in MonkeyX. E.G. #CC_OPTS+="-ldl" http://www.monkey-x.com/docs/html/Programming_App%20config%20settings.html For BlitzMax it's Import "-ldl" |
| ||
| I added it ages ago into appstub.bmx but it still errors. Will try adding it to monkey :) |
   |