-
Notifications
You must be signed in to change notification settings - Fork 6.4k
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
[GDAL] On Linux completly broken #9068
Comments
This is a common problem with almost every port that uses configure / make. and I meet it almost every day. I think I should add a public function like What really bothers me is those ports that don't support using @ras0219-msft What do you think? |
I added a cmake function |
@JackBoosY I'd be happy to help with this, if it's possible. Just let me know. |
I stumbled upon a problem which I find related to this. We tried to build proj4 with dynamic linking (since gdal 2.4.1 at least seems to want libproj.so at runtime rather than compile-time linking with it, so it seemed like a first step to build it) I used the steps at https://github.com/microsoft/vcpkg/blob/master/docs/examples/overlay-triplets-linux-dynamic.md#overriding-default-triplets I build proj4 through However, building proj4 as a shared library seems to be non-trivial with how sqlite3 is built, the The proj4 command that breaks for me: ldd output for the sqlite3 binary:
I could go and setup LD_LIBRARY_PATH to the lib folder of vcpkg, but I feel like that defeats the purpose... |
I'd like to indicate that I'm trying to improve the Unix part of the gdal portfile. At the moment I'm about to establish a fit between explicit dependencies from vcpkg.json and configuration options. However, this may be a long walk, in particular with correctly handling transitive dependencies and debug variants. |
This problem extends to macOS triplets, or basically to all triplets which need |
PRs or issues this depends on directly or transitively (unless eventually resolved by patching gdal):
|
@Neumann-A Thanks. The main problem is that gdal uses (at least) three different mechanism. So my current approach is to standardize around pkg-config with patches for now, and propose similar changes to upstream. Only that I never worked with
|
Would it help to build gdal through cmake, either by including it here or upstream? CMakeLists exist https://github.com/miurahr/cmake4gdal (I don't know their quality) |
@m-kuhn AFAICT this is all too fragile, in particlar if you want to pick gdal updates quickly. For the full history, there is also OSGeo/gdal#664, and it references https://trac.osgeo.org/gdal/ticket/7080. It is not too hard to build gdal cross-platform with autotools ... if you get the right configuration details from the dependencies. |
Thanks for the context, I wasn't aware of the trac and closed gh tickets. I'm very familiar with cross comipiling gdal. Not so much with the dependency discovery (especially in the vcpkg context but also otherwise). |
This issue should be fixed now. |
Thanks for taking care @dg0yt much appreciated! |
This port does not build correctly on linux. (even though it builds succesfully)
It does not pass any option of 3rd party libraries and the configure discovery of libraries of this port is terrible broken which can be seen by simply looking at the config-x64-linux-(rel|dbg)-out.log.
As an example: gdal depents on sqlite3 but the configure log tells:
the reason why configure fails is due to undefined symbols due to not linking pthread and dl in the test (the script even sets LIBS='' for the test so i cannot pass those via the LIBS variable).
To solve the problem all libraries must be passed via
-with-<package>=${CURRENT_INSTALLED_DIR}/(debug/)
in addition to that the configure script itself must be patched. Furthermore the configure file in the debug build must be changed so that every occourence of-with-<package>/include
is replaced by-with-<package>/../include
due to additional header existence checks (WTF?!? Why? You already did compiler/linker checks .....)(and that might not be all)
Here is a list of all gdal configure options for reference:
Finally, I think we should break the build of the port on linux completly instead of allowing this mess.
The text was updated successfully, but these errors were encountered: