Aurel300/ammer

Linux support in samples/poc

jcward opened this issue · 10 comments

jcward commented

I'd like to see a linux section in the README, and a Makefile.linux. I'm not super familiar with native workflows, but I'm guessing the Makefile.linux would be something like:

all: libadder.so adder.o

libadder.so: adder.o
	gcc -shared -fPIC -o libadder.so adder.o -lc

adder.o: adder.c
	gcc -c -fPIC -o adder.o adder.c

.PHONY: all

I'd be happy to test the workflow. Let me know if you have input on the above.

Aurel300 commented

Yup, currently working on this :)

jcward commented

Ok, it worked for me!

cd samples/poc
cd native
make -f Makefile.linux
cd ..
haxe build-cpp.hxml
LD_LIBRARY_PATH=./native ./bin/cpp/Main

image

larsiusprime commented

That was fast

jcward commented

I feel like I should kick in $50 -- the amount of documentation is above and beyond. 👍

So, while you're here, @larsiusprime or @Aurel300 -- is there a recommended way to deliver your libraries and launch the exec in Win / OSX / Linux? Do you make a .bat / .sh launcher file that sets ??? / LD_LIBRARY_PATH / DYLD_LIBRARY_PATH and calls the executable?

larsiusprime commented

@jcward -- I'm not 100% qualified to answer this, but here's what I had to do to get Defender's Quest to work with hxcpp Steamwrap

  • Windows: just put the steam api dll's in the right the place next to the steamwrap ndll. So basically just copy files after building.
  • Mac OS: just put the steam api dylib's in the right place in the .app bundle along with the steamwrap ndll. So basically just copying files again after building.
  • Linux: I had to set a launcher option in steam to call an .sh script instead of the main executable that would set some library paths and then call the executable, along with making sure my steam library files were in the right place next to the steamwrap ndll
Aurel300 commented

Yup, the Makefile worked, thanks @jcward. I also added -fPIC in the hdll compilation stage because the compiler shouted at me.

Aurel300 commented

As for the library paths, yes, each platform is different, with Windows being the simplest to support since it searches the CWD by default. On OS X there is this @executable_path attribute (see the link in the README) which should be used somehow. I don't think this is in scope for ammer, it is something a "packager" should be doing.

larsiusprime commented

Possibly something worth mention in documentation though?

"Things you ought to take care of yourself since they're not within ammer's scope:"

larsiusprime commented

Duh, you already did exactly that.

  • 🚀1
jcward commented

Is it fair to close this issue before the pod/README.md is updated -- Gah, look what commit just came in. 😆

  • 🚀1