full Ubuntu VM

Monkey Archive Forums/Monkey Discussion/full Ubuntu VM

AdamRedwoods(Posted 2013) [#1]
https://koding.com/

SO I'm trying to get monkey working on this, and was able to compile transcc (use the ace app, and copy paste from my laptop), but cannot run the file. Anyone know how to get this going? I have the chmod +x, but still nothing happens.

i know little about linux.

Edit:
"./transcc" WTF? where do i need to put this to work as a command?

Edit:
almost worked, but gave up. was fun trying.


DruggedBunny(Posted 2013) [#2]
If you're in the same directory as a command you need the ./ at the start, otherwise you don't. Think it's some weird safety feature...


EdzUp(Posted 2013) [#3]
To get it working I had to install the same stuff as for blitzmax then it worked perfectly
http://www.blitzbasic.com/Community/posts.php?topic=88613

There are others that ya enter into terminal as well :-)


dawlane(Posted 2013) [#4]
@DruggedBunny:
./ Isn't a safety feature. It's a short hand for executing either a script file or a binary "file" (that's why there is a forward slash in it).

@EdzUp:
You don't need the same dependencies that BlitzMax does. All you should need are the mesa glu and openal development files. You will still need to install the SDK's for the other targets.

I should point out that if you are developing on a 64bit system and you don't install the 32bit dependencies and associated links to those dependencies, along with a modified makefile template then you will by all accounts generate 64bit applications. Also on a 64bit system you will have a few problems with Ted as well with it being 32bit.

May be I should do a tutorial on how to set Monkey up on linux? Let's see how many votes that gets.


AdamRedwoods(Posted 2013) [#5]
SO is the 32-bit better for testing? I'll just install that then.


zoqfotpik(Posted 2013) [#6]
If you're in the same directory as a command you need the ./ at the start, otherwise you don't. Think it's some weird safety feature...


It's to prevent bad people from putting a bad ls or something in a directory somewhere, knowing that root would eventually go there and run ls and instead would run the bad ls with root privs :)


wiebow(Posted 2013) [#7]
Well, no. It's to inform the shell that the command entered is present in the current directory, so that root dir or PATH variable are not used, and it also enables you to use commands in a directory which is not in the PATH variable.


dawlane(Posted 2013) [#8]
A description of the dot operator can be found at http://www.ss64.com/bash/source.html and here http://www.gnu.org/software/bash/manual/bashref.html#Shell-Builtin-Commands

It's to prevent bad people from putting a bad ls or something in a directory somewhere, knowing that root would eventually go there and run ls and instead would run the bad ls with root privs :)
In 12 years of using Linux, I have never heard that one. And besides if a bad person has managed to install a malicious script or binary in those locations that only root can install or a user with root privileges runs a unknown script or binary from any location then the system is well and truly screwed.

The real security features on any *nix system is file permissions and the firewall. Unfortunately many people don't know how to use both, some don't even bother to check that the firewall is turned on and what ports are open.

SO is the 32-bit better for testing? I'll just install that then.
If your just trying out Monkey then yes, but remember not to expect it to be lighting fast running as a virtual machine. If you plan on releasing binaries that are going to target both the 32bit and 64bit OS's. Then you will need to use the 64bit OS and set it up in such away that you can compile and run binaries for both architectures. If I remember Flash SDK also needs some 32bit libraries to be present.

One problem in doing a cross glfw compilation with Monkey is that as there is no way to tell the compiler from within Monkey as to which architecture you wish to build, so your basically stuck with modifying the Makefile directley in targets/glfw/template/gcc_linux and adding or removing the -m32 option switch to CPPFLAGS and LDFLAGS. Another thing to remember is, that any previous .build directory has to be removed. It is possible just change the makefiles in the .build directory but you have to make sure that all object files with the .o extension are removed or the linker has a fit.


AdamRedwoods(Posted 2013) [#9]
great points, thanks for the info.
One problem in doing a cross glfw compilation with Monkey is that as there is no way to tell the compiler from within Monkey as to which architecture you wish to build

I recently forced a Pull on Monkey to allow this in the cpp target. (#CCOPTS="")
I expect it may appear at some point in GLFW.


xlsior(Posted 2013) [#10]
./ Isn't a safety feature. It's a short hand for executing either a script file or a binary "file" (that's why there is a forward slash in it).


Except it is a safety feature:

. just means 'current folder' just like .. means 'parent folder' and ../../../ means 'three folders up'
Even under windows you can see this: Any time you do a directory listing, you'll ways see . and .. listed as two folders. Those behave the same as under Linux.

By being required to running a program in your local folder as ./whatever it supersedes whatever is in your local path... The advantage of requiring the ./ is that you can't have a program easily hijack one of your system commands because typing 'ls' will grab the one from your normal path, instead of the compromised ls executable that may exist inside an application folder...


zoqfotpik(Posted 2013) [#11]
Weibow the reason why it is required for you to specify the whole path is to prevent you from unintentionally running the wrong binary which might be in your current directory. In the late 80s a lot of trojan exploits involved getting root to go to a certain directory where there was a doctored binary for ls. He would type ls to see what was there, and unintentionally run your binary or shellscript with root privileges which would own the system, delete itself and run the real ls command, leaving root none the wiser.

Dawlane: you never heard of it because it stopped happening around 25 years ago. It was long before linux. I know about it because I lived in the terminal and sun labs at the time.