Lubuntu Compiling issues

Archives Forums/Linux Discussion/Lubuntu Compiling issues

Vanessa

(Posted 2015) [#1]

I've compiled an app to run in command line, though it has the ability to call gui modules, they're not run by default. If I run it in a terminal emulator, such as LXTerminal, the program runs without issue. However, if I run it from a TTY line, it returns a Segmentation Fault (core dumped) error. This happens regardless if it is compiled as a GUI app or not from the build options.

Is this caused by the fact that it can launch a GUI window, even if it it isn't currently? Would the only way to get a version that can run strictly in CLI (TTY) mode be to create a version that drops support for the GUI completely?

It's also threaded, could that have something to do with it?

Ideally I'd like a single version that can be run from either the GUI or CLI and either create a GUI window or run strictly in CLI depending on the situation if at all possible. (Currently called based on the command line parameters.)

Any ideas?

Yasha

(Posted 2015) [#2]

I don't have a solution/explanation, but in the past I found that in some situations (i.e. building on Debian), BlitzMax couldn't compile an app that worked at all: even an empty application would segfault immediately - if I built in Release mode. In Debug mode, the application worked as expected, so as a workaround I just stuck to Debug builds.

Vanessa

(Posted 2015) [#3]

Well I can say for certain that it's not an issue with the GUI functions being there. I just compiled a version without them completely and still segfault is the result in TTY mode. Also, I tried building it in debug mode, same result, even with the CLI only build.

skidracer

(Posted 2015) [#4]

Unfortunately system.linux.bmx has not been able to run headless for sometime as it has runtime dependency on Xxf86vm which needs to be removed.

You should then be able to use the Framework command to build a lightweight blitzmax app that will run on any server.

Vanessa

(Posted 2015) [#5]

How would I go about doing that? I've looked over what documentation I can find on the topic but I'm kind of lost. How do I know what modules to use?

Also, what even is Xxf86vm? I can't seem to find much information on it other than other people just as baffled as I am.

Floyd

(Posted 2015) [#6]

Framework Assistant by Jim Brown is the easy way to build a framework. I've only used the Windows version and don't even know where to find the Linux one.

For the rest of it I don't have a clue. A look at system.linux.bmx shows that it does

Import "-lXxf86vm"

So you have to get rid of that.

Then what, rebuild the module? All modules? I don't know.

skidracer

(Posted 2015) [#7]

There are some old notes here. I'm not sure it will be much help but I was able to get linux binaries running on my Amazon cloud account with blitzmax after some tinkering.

As for framework the simplest exe you can build with bmx is this:

Framework brl.standardio
Print "hello"

As you add commands to the above you will need to also add imports for the modules you use. If you can avoid System you may be OK for simple server apps.

With TTY testing, which seg fault? Are you the same user with same credentials?
Does above "hello" program work?

Brucey

(Posted 2015) [#8]

Unfortunately system.linux.bmx has not been able to run headless for sometime as it has runtime dependency on Xxf86vm which needs to be removed.

That's why I split the system module into two parts, one with the core stuff, and the other with the "UI/event handling" related stuff.

That way I can implement different "systems" depending on what I need - for example, a curses-based system, or an SDL system, etc.

This strategy is based much in the same way as image and audio loading is abstracted.

I also did this for pub.joystick, so I could implement custom joystick drivers (like a virtual joystick for touch devices).

A bit more abstraction lets you do so much more...

Vanessa

(Posted 2015) [#9]

I just tried that hello program and same results.

Yes, I am using the same account I used to execute it in LXTerminal.

Unfortunately it looks like the Framework Assistant is only available for Win32 so that doesn't help any.

I tried commenting out that Import "-lXxf86vm" line, rebuilding the modules and alas, the segfault returns.

I'm running Lubuntu 15.04 x86 if it helps.

skidracer

(Posted 2015) [#10]

It could be anything. Perhaps std err is null and you are trying to run a debug build.

I see a few options, share the sigfault info, learn/run gdb session, switch to the NG toolchain, walk away.

Brucey

(Posted 2015) [#11]

I just tried that hello program and same results.

The program segfaults?

Have you tried gdb, as skid mentions?

From the app dir :

gdb ./appname

Then 'r' for run.

When it crashes, you can 'bt' to get a backtrace, which should give you the callstack at the time it went bang.

Derron

(Posted 2015) [#12]

For non "NG"-builds you get just empty lines on some segfaults - with only one "entry" being filled with a not that useful information (some library path).

So you do not get the function calls in all situations (had this problem on the laptop segfaulting on "NextNode()" of a TMap - with the code compiling /running flawless on other computers).

bye
Ron

Brucey

(Posted 2015) [#13]

I'm running Lubuntu 15.04 x86 if it helps.

I just installed this, installed dev packages, and installed BlitzMax 1.50.

Built the "hello" example, and ran it in a tty. It displayed the text as expected and did not segfault. (this applies for both debug and release builds)

BlitzMax programs work fine headless, in my experience.

Vanessa

(Posted 2015) [#14]

Just tried using gdb as recommended.

The result was this:

Program received signal SIGSEGV, Segmentation fault.
0x804db63 in ?? ()

backtrace:

#5 oxb7d8f72e in _libc_startmain (main = 0x804900, argc = 1, argv = 0xbffffc34, init = 0x804fa00, fini = 0x804fa60, rtld_fini = 0xb7feb310 <_dl_fini>, stack_end = 0xbffffcc2c) at libc-start.c:289
#6 0x080498b2 in ?? ()

Any ideas? I'm compiling with:
MaxIDE version 1.43
BCC version 1.50
FASM Version 1.68
GCC Version 4.9.2
G++ Version 4.9.2

It's on an old Acer laptop.

Any ideas why this could be happening considering Brucey got it to run?

Vanessa

(Posted 2015) [#15]

Ok, I don't know necessarily what exactly happened to cause this, but I started to wonder if my installation of MaxIDE had gotten messed up somewhere along the line because he was able to get it to run, so I deleted mine and downloaded a fresh copy. After compiling the hello example from there, it worked! No segfault! So that is resolved now.

Now I just need to figure out which modules I actually need for my actual program. Is there a guide somewhere that someone can point me to or is there a Linux version of that Framework Assistant floating around somewhere that I could grab?

EDIT: Found the module guide in the IDE's documentation so I'm going to read through that.

skidracer

(Posted 2015) [#16]

I would try adding something needing system next:

Framework brl.standardio
Import brl.system

Print "size of desktop is "+DesktopWidth()+"x"+DesktopHeight()

Vanessa

(Posted 2015) [#17]

I was able to figure out what modules my program needed by using the documentation provided with the IDE. My CLI variant of my program is now compiled and running without issue in TTY mode.

Brucey

(Posted 2015) [#18]

Yay! :-)

Derron

(Posted 2015) [#19]

That backtrace is something I get on some debug builds too ... not many clues included then :-)

BTW: TMap-Segfault also only happened on an old Acer-Laptop ... coincidences everywhere.

Just for the knowledge base: did you use recompiled modules when your code crashed or just the ones you "unzipped"?

bye
Ron

Vanessa

(Posted 2015) [#20]

The recompiled modules were the ones that caused the crash. The ones extracted from the tarball were the ones that worked.

It's up on my Amazon AWS server and running now.

Derron

(Posted 2015) [#21]

Hmmm.. I guess you have compiled them with "gcc 4.8.2" ? (gcc -v)

Have running these version on multiple computers but happened only to the "32 bit" variant for now. Maybe some trouble with that gcc-suite?

bye
Ron

Vanessa

(Posted 2015) [#22]

As stated above, the version of gcc I am using is 4.9.2

Could this be the source of the issue with compiling the modules? Is there something about this version that conflicts with BlitzMax or otherwise doesn't work right?

Derron

(Posted 2015) [#23]

Ahh, sorry, missed that spot.

I do not know with what compiler Mark precompiled his modules (included in the download)... there might be issues, but somehow I doubt that as bug reports would come in very fast with the "default" variants of GCC on linux ...

Maybe it is more one of the system libs it links to ... but even then: why is it not segfaulting on "more" machines.

Nonetheless... you fixed it for yourself, so we might save some breath now.

bye
Ron

dawlane

(Posted 2015) [#24]

For 1.50 Linux the compiler used was GCC: (Ubuntu/Linaro 4.6.3-1ubuntu5) 4.6.3. Easy to obtain as long as the binaries haven't been stripped of debug symbols. BMK is sloppy when it comes to removing these for the release version.

@Derron: I think that I would be investigating compiler option settings if there is a difference in the hardware. Plus I would be having a look at what FASM is up to. The current version with the vanilla 1.50 download stands at 1.68, while the latest is 1.79.39.

Derron

(Posted 2015) [#25]

Do you talk about the "configured with" parts of GCC ?
In that case you get the only difference is

--with-arch-32=i686
vs
--with-arch-32=i686 --with-abi=m64

rest (except for "i386" versus "x64") is the same.

Any hints how to check for "hardware differences" (I am talking about compiler specific things, not the general "what cpu is it?") ?

FASM is on both incarnations (laptop + desktop) on "vanilla". I never updated FASM on linux, just on the windows VMs.

Since "4.6.3" the only "visible" change for me was the increased filesize ... the newer binaries tend to include more stuff (stripped at the end...).

What differs between "laptop" and "desktop" is: desktop uses Bruceys BMK and bmk-files (to strip the binary at the end ...). My "custom.bmk" has the "optimization params" commented out, so that does not differ. A project specific.

post.bmk

@define doPostInstall
	# MAC: replace icon when doing a GUI build (aka "package")
	if bmk.Platform() == "macos" and bmk.AppType() == "gui" then
		#replace icon
		sys.CopyFile( %buildpath% .. "/Misc/appData/mac_icon.icns", %exepath% .. "/../Resources/" .. %outfile% .. ".icns" )

		#touch the icns file so some kind of "mac cache" gets redone
		bmk.Sys( "touch " ..  %exepath% .. "/../Resources/" .. %outfile% .. ".icns" )

		#replace info.plist
		#sys.CopyFile( %buildpath% .. "/Misc/appData/info.plist", %exepath% .. "/../info.plist" )
	end


	# LINUX/MAC: strip binary when doing a releasebuild
	if bmk.Platform() == "macos" or bmk.Platform() == "linux" then
		if bmk.IsDebugBuild() == 0 then
			if bmk.Platform() == "linux" then
				bmk.Sys( "strip --strip-all " .. %exepath% .. "/" .. %outfile% )
			elseif bmk.Platform() == "macos" then
				bmk.Sys( "strip " .. %exepath% .. "/" .. %outfile% )
			end
		end
	end
@end

# run the post install
doPostInstall

So it just strips the binary. This is _not_ done on the laptop.

bye
Ron

Vanessa

(Posted 2015) [#26]

I tried compiling them with Brucey's BMK to see if it would make a difference, but I couldn't get it to play nicely with the version of gcc and g++ I have. I was able to downgrade my version of gcc and get it to work, but I couldn't seem to find a repository that has the version of g++ that I saw elsewhere on the forum that the BMK was designed to work with so it kept just throwing up errors regarding unrecognized command line parameters.

I don't have the laptop in front of me right now or I'd copy and paste the error message.

The inability to successfully compile the modules has become a problem on my new project because I'm actually planning on using some of Brucey's modules and they keep failing to compile, so I guess this issue is not really solved, just delayed. I'm going to go ahead and change the topic title to be more applicable.

dawlane

(Posted 2015) [#27]

Do you talk about the "configured with" parts of GCC ?

Well if I remember if you don't pass a specific march/mtune it defaults to generic. The general idea I get from the GCC manual is that it can change depending on what CPU's are popular at the time of a GCC release.
I would try forcing march/mtune to something like the last Pentium 4 (code name 'nocona') or Athlon K8 with the -m32 compiler flag. If you tried anything lower I would think that you wouldn't get later versions of BlitzMax to compile.

Edit: Almost forgot. Check out the -fabi-version C++ dialect option. And remeber the -std option in C dialect options.

Any hints how to check for "hardware differences" (I am talking about compiler specific things, not the general "what cpu is it?") ?

g++ -march=native -Q --help=target
See --help=class[,qualifier] in https://gcc.gnu.org/onlinedocs/gcc-4.3.5/gcc/Overall-Options.html#Overall-Options
The main ones are common, target and optimizers.

Derron

(Posted 2015) [#28]

Difference between "desktop" (AMD machine, 64bit linux) and "laptop" (old Intel machine - _single_core_ !, 32bit linux)

--- /home/ronny/Arbeit/Programmieren/BlitzMax/bin/native.txt
+++ /home/ronny/Arbeit/Programmieren/BlitzMax/bin/native2.txt
@@ -1,14 +1,14 @@
 The following options are target specific:
   -m128bit-long-double        		[disabled]
-  -m32                        		[disabled]
+  -m32                        		[enabled]
   -m3dnow                     		[disabled]
   -m3dnowa                    		[disabled]
-  -m64                        		[enabled]
+  -m64                        		[disabled]
   -m80387                     		[enabled]
   -m8bit-idiv                 		[disabled]
   -m96bit-long-double         		[enabled]
   -mabi=                      		sysv
-  -mabm                       		[enabled]
+  -mabm                       		[disabled]
   -maccumulate-outgoing-args  		[disabled]
   -maddress-mode=             		short
   -madx                       		[disabled]
@@ -19,7 +19,7 @@
   -malign-loops=              		0
   -malign-stringops           		[enabled]
   -mandroid                   		[disabled]
-  -march=                     		amdfam10
+  -march=                     		core2
   -masm=                      		att
   -mavx                       		[disabled]
   -mavx2                      		[disabled]
@@ -58,7 +58,7 @@
   -mlong-double-64            		[disabled]
   -mlong-double-80            		[enabled]
   -mlwp                       		[disabled]
-  -mlzcnt                     		[enabled]
+  -mlzcnt                     		[disabled]
   -mmmx                       		[disabled]
   -mmovbe                     		[disabled]
   -mms-bitfields              		[disabled]
@@ -72,10 +72,10 @@
   -mpc64                      		[disabled]
   -mpc80                      		[disabled]
   -mpclmul                    		[disabled]
-  -mpopcnt                    		[enabled]
+  -mpopcnt                    		[disabled]
   -mprefer-avx128             		[disabled]
   -mpreferred-stack-boundary= 		0
-  -mprfchw                    		[enabled]
+  -mprfchw                    		[disabled]
   -mpush-args                 		[enabled]
   -mrdrnd                     		[disabled]
   -mrdseed                    		[disabled]
@@ -104,7 +104,7 @@
   -mtbm                       		[disabled]
   -mtls-dialect=              		gnu
   -mtls-direct-seg-refs       		[enabled]
-  -mtune=                     		amdfam10
+  -mtune=                     		generic
   -muclibc                    		[disabled]
   -mveclibabi=                		[default]
   -mvect8-ret-in-mem          		[disabled]

So what differs:
-mabm (AMD - enabled, INTEL - disabled)
-march (amdfam10, core2)
-mtune (amdfam10, generic)

So, while "march" uses some specific things (intel celeron m is a sprout of the "core 2" I think), the "mtune" option is set to "generic".

@Brucey's BMK

Just make sure you copy the "core.bmk" next to Bruceys BMK (BlitzMax/bin), custom.bmk is only needed if you want to adjust some settings (compiler optimization).

It should not really matter what kind of gcc/g++ is used (as long as it isnt a longly outdated one ... a v2.0.0). Exception is, if you use some of Bruceys modules (with their library binding/wrapping). Nonetheless I normally did not have problems on the linux machines regarding his extended BMK.

Maybe it helps to print, what kind of command line parameters are throwing errors (... when you are at your laptop again).

bye
Ron

Brucey

(Posted 2015) [#29]

... and "make.bmk" ...

Derron

(Posted 2015) [#30]

Absolutely right, had my file explorer on "sort by date" and the other ones there at the bottom, with "make.bmk" being hidden inbetween some other files.

Forgive my mistake, but my mind is somewhere else (new and shiny, with 2 legs, 2 arms and a face similar to mine :-))

bye
Ron

LT	(Posted 2015) [#31]

new and shiny, with 2 legs, 2 arms and a face similar to mine

Your robot avatar is finally complete? ;)

Derron

(Posted 2015) [#32]

Yepp.. Wifey construction farm took 9 months to complete. At the end production line halted in C-Section and the Master Chief took it into his hands.
Now batteries loaded for a week in hospital and tomorrow it is ready to grow (self-learning AI !).

But thanks for the laugh :-)

bye
Ron

Vanessa

(Posted 2015) [#33]

Per the included readme I didn't use custom.bmk

I was trying to setup the cross-compiling as well so I followed those instructions with setting it up as best as I could follow. (The instructions mention a lib folder in the bmk's archive but I only had a bmk_ng folder so I put all of it's contents into the bin folder, I hope that was the right step.)

Anyways, here's the ouput when I compile:

 Building hiscoreserver
Compiling:hiscoreserver.bmx
flat assembler  version 1.68  (32768 kilobytes memory)
4 passes, 21291 bytes.
Linking:hiscoreserver.mt
g++: error: unrecognized command line option â--eh-frame-hdrâ
Build Error: Failed to link /home/vanessa/Dropbox/VanessaSoft/BlitzCode/BlitzMax/HiscoreServer/hiscoreserver.mt
Process complete

Running build all modules failed with some of Brucey's modules mostly due to includes that were called in the c code didn't exist in the archive, but those were on modules I wasn't planning on really using anyway so I just deleted them. I assume that was the library binding you were talking about.

Derron

(Posted 2015) [#34]

â--eh-frame-hdrâ

Copy-Paste-Failure - or really such an encoding "garbage" in the console?

Before getting "cross-compiling" to work I would guess you will have to fix the issues with the "native build process".
For Windows builds I just use a VM with an XP installation (+ BlitzMax Win32) - as I was not able to install the needed things on my 64bit setup and did not want to annoy Brucey with my cries for help :-).

BTW for your error:
Happened with v4.4 too
or here

bye
Ron

dawlane

(Posted 2015) [#35]

(intel celeron m is a sprout of the "core 2" I think)

Celeron is a brand name use by Intel to denote budget CPU's and could be based on any of the mainstream CPU's that they have produced over the years. Though they are more likely the mainstream CPU's that have production flaws. e.g. Cache memory or a core not working.

Vanessa

(Posted 2015) [#36]

Really such "garbage" in the console.

I'm not that worried about cross compiling, I just want it to work. I just figured while I was at it since Brucey's BMK does cross-compiling that I would go ahead and follow those steps as well.

I will try to downgrade my g++ and see if that works, but I was having trouble finding the packages for it the last time I tried downgrading to a previous version. (again, not home at the moment)

Brucey

(Posted 2015) [#37]

Hallo :-)

I got lost in those posts somewhere along the way.

Can we summarise what is and isn't working at the moment?

I have a default Lubuntu distro that builds BlitzMax 1.50 and appears to great apps that don't segfault. The default gcc is 4.9.2.
Everything else is standard as per what comes in the BlitzMax 1.50 gz file.

bmk_ng, generally wouldn't help compile stuff if the default install wasn't working.
You don't need any of my modules to build bmk_ng, so I presume you were needing something from there for your project.

With this version of Linux, everything should 'just work'. If it doesn't then I'd say either 1) your install of BlitzMax is bad, 2) you've installed other stuff on Linux that is causing problems.

:o)

Derron

(Posted 2015) [#38]

@ Brucey
Lubuntu 15.04 x86 ?
This is what Vanessa is using.

If Vanessa is at home/at her computer she could try whether installing her distribution in a VM is working fine with BlitzMax.

As BlitzMax is "portable", she could compare the VM-BMX-install with the one on her normal installation (directory compare).

bye
Ron

Brucey

(Posted 2015) [#39]

I don't see why. It shouldn't make any difference. That's the whole point of VM's. They are the same as running it standalone on a computer.

Derron

(Posted 2015) [#40]

If it works in a VM she probably changed something in her normal distro-installation (borked blitzmax directory - or install of something "more/less").

@x86
Are you running x86 too or 64bit?

bye
Ron

Brucey

(Posted 2015) [#41]

I installed the exact same version as Vanessa mentioned in #9. Otherwise it would be difficult to determine common faults, if any.

Derron

(Posted 2015) [#42]

I did not want to express that you did not pay attention, I just wanted to make sure so everything started of the same base.

We will see if the "VM-installation" runs flawless (I assume so...) and then it's up to find out what differs between "normal" and "vm"-installation (different packages or so).

bye
Ron