Skip to content
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

Better way to write native files #9

Open
Gigas002 opened this issue Jan 1, 2020 · 1 comment
Open

Better way to write native files #9

Gigas002 opened this issue Jan 1, 2020 · 1 comment
Labels
enhancement New feature or request

Comments

@Gigas002
Copy link

Gigas002 commented Jan 1, 2020

Hello.
I'm using this package along with others projects on Linux. After building the project with MaxRev.Gdal.LinuxRuntime.Minimal package, it writes Linux dependencies in "runtimes/linux-x64/native" directory.
However, another library writes its dependencies the same way and Gdal's dependencies overrides some files there. Because of that, NetVips in my application doesn't work, throwing the exception:

Message [string]:"Unable to load shared library 'libvips.so.42' or one of its dependencies. In order to help diagnose loading problems, consider setting the LD_DEBUG environment variable: liblibvips.so.42: cannot open shared object file: No such file or directory"

Probably the native binaries should be written the other way to avoid these conflicts?

@MaxRev-Dev
Copy link
Owner

MaxRev-Dev commented Jan 1, 2020

We can try to move gdal libraries to separated folder.
This will affect:

  • Linker (linkall and csharp_modules targets in GNUMakefile).
  • Output folder ($output in GNUMakefile).
  • GdalBase.Configure method (drivers path for Linux runtime).

The same thing is for Windows if you are using projects with different VC++ versions or other libraries those leads to dependencies collision.
Is it worth it? I mean, you can try to create a wrapper project with a separated workdir.

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

No branches or pull requests

2 participants