Skip to content

improvements: make this library importable instead of forcing it to be the top level. #3

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
james-lawrence opened this issue Sep 9, 2018 · 8 comments · Fixed by #4
Labels
enhancement New feature or request

Comments

@james-lawrence
Copy link
Contributor

james-lawrence commented Sep 9, 2018

still playing with the code, but think this should work closer to how go-gl/glfw works where you can just import and go.

  • figure out a way of statically linking the flutter engine.
  • remove main function and expose a top level package function that perform the same work.

been working on getting these changes to work running into issues with the shared library, which i haven't had a chance to track down. basically go is having trouble loading the library but isn't being clear on where its looking.

@pchampio
Copy link
Member

pchampio commented Sep 9, 2018

Make a go library is intended. But, for now, I am focusing on making the proof of concept work on multiple platforms.
Regarding the static linking, this would be awesome, but sadly I don't think it's possible without having to compile the entire Flutter-Engine at the same time as a go library.

go is having trouble loading the library but isn't being clear on where its looking.

Could you be more specific? (If I can help).

@james-lawrence
Copy link
Contributor Author

james-lawrence commented Sep 9, 2018

i'm working towards the library functionality, so I customized your code atm.

basically this

problem is the flutter shared library is nested in vendor.
I tried putting the same directory structure in my working directory but it failed.
i suspect I need to adjust the cgo directives to not contain the ${SRC} variables but havent gotten around to it yet and probably done for the day.

@james-lawrence
Copy link
Contributor Author

biggest help would be finding where go does its shared library loading so I can debug where its looking, though I suspect its coming from a native library go calls out to.

@pchampio
Copy link
Member

pchampio commented Sep 9, 2018

Go is loading the shared library on this line. The -rpath flag might be the cause.

Try to add the .so to your path with something like export LD_LIBRARY_PATH=$GOPATH/src/github.com/Drakirus/go-flutter-desktop-embedder/flutter/library/linux.

@james-lawrence
Copy link
Contributor Author

oh I know where it was in repo, I was being very literal about trying to find out where go runtime attempts to do the loading.

basically getting this error:

error while loading shared libraries: libflutter_engine.so: cannot open shared object file: No such file or directory

and I can't find any of those strings in the go runtime =(

@pchampio
Copy link
Member

pchampio commented Sep 9, 2018

And I am guessing that objdump -p go-flutter-desktop-embedder doesn't give you anything?

@james-lawrence
Copy link
Contributor Author

havent dug that far yet. will dig more when I get back to it later tonight or next week.

@james-lawrence
Copy link
Contributor Author

alright you were correct on rpath being the issue. removing $ORIGIN/ from it let the runtime find the library.

would you like a PR making the minor adjustments?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Development

Successfully merging a pull request may close this issue.

2 participants