#45331: issues with port:libkgapi: case-folding and exported symbols --------------------------+--------------------- Reporter: rjvbertin@… | Owner: nicos@… Type: defect | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.1 Resolution: | Keywords: Port: libkgapi | --------------------------+--------------------- Changes (by ryandesign@…): * cc: nicos@… (removed) * owner: macports-tickets@… => nicos@… Old description:
libkgapi installs both C-style headers (with .h extension), and C++-style "proxies" without extension and using capitalised names, e.g. LibKGAPI2/Drive/File, which includes /opt/local/include/libkgapi2/drive/file.h .The packaging process used by the buildbots fails to reflect this (as presumably does the install-from- source process) on a case-insensitive host.
I think what happens is this:
- port installs to ${destroot}/opt/local/include/LibKGAPI2/Drive/File ## works fine, case will be preserved ... - port installs to ${destroot}/opt/local/include/libkgapi2/drive/file.h
and there things go wrong. A case-insensitive HFS+ fs will already have libkgapi2/drive, only with a different case. That case is adapted, and file.h is written in a directory that now holds all include files.
This is likely (though not certain) to work when building from that case- insensitive fs and including <LibKGAPI2/Drive/File> (example: kdepim4's pimcommon component) if the compiler simply asks the fs to open that file, without checking for its presence (a filename based check will of course fail unless it too is done in case-insensitive mode). On a case- sensitive fs, that include statement will fail.
The second issue concerns the visibility of library symbols on OS X 10.6.8, when building with Apple's clang-3.0 or clang-mp-3.4 . Linking kdepim4's pimcommon, (almost) none of the functions for Google Drive functionality are visible. For instance, clang-3.0 will complain about __ZN6KGAPI27Account14setAccessTokenERK7QString (clang-3.4 unmangles that name).
Built with clang, I get
{{{
nm /opt/local/lib/libkgapi2.2.1.1.dylib | fgrep __ZN6KGAPI27Account14setAccessTokenERK7QString ... t __ZN6KGAPI27Account14setAccessTokenERK7QString }}}
built with Apple gcc 4.2, I get
{{{
nm /opt/local/lib/libkgapi2.2.1.1.dylib | fgrep __ZN6KGAPI27Account14setAccessTokenERK7QString ... T __ZN6KGAPI27Account14setAccessTokenERK7QString }}}
the difference between 't' and 'T' explains everything, AFAIK (but not why both compilers give such different results).
New description: libkgapi installs both C-style headers (with .h extension), and C++-style "proxies" without extension and using capitalised names, e.g. LibKGAPI2/Drive/File, which includes /opt/local/include/libkgapi2/drive/file.h .The packaging process used by the buildbots fails to reflect this (as presumably does the install-from- source process) on a case-insensitive host. I think what happens is this: - port installs to ${destroot}/opt/local/include/LibKGAPI2/Drive/File ## works fine, case will be preserved ... - port installs to ${destroot}/opt/local/include/libkgapi2/drive/file.h and there things go wrong. A case-insensitive HFS+ fs will already have libkgapi2/drive, only with a different case. That case is adapted, and file.h is written in a directory that now holds all include files. This is likely (though not certain) to work when building from that case- insensitive fs and including <LibKGAPI2/Drive/File> (example: kdepim4's pimcommon component) if the compiler simply asks the fs to open that file, without checking for its presence (a filename based check will of course fail unless it too is done in case-insensitive mode). On a case-sensitive fs, that include statement will fail. The second issue concerns the visibility of library symbols on OS X 10.6.8, when building with Apple's clang-3.0 or clang-mp-3.4 . Linking kdepim4's pimcommon, (almost) none of the functions for Google Drive functionality are visible. For instance, clang-3.0 will complain about `__ZN6KGAPI27Account14setAccessTokenERK7QString` (clang-3.4 unmangles that name). Built with clang, I get {{{
nm /opt/local/lib/libkgapi2.2.1.1.dylib | fgrep __ZN6KGAPI27Account14setAccessTokenERK7QString ... t __ZN6KGAPI27Account14setAccessTokenERK7QString }}}
built with Apple gcc 4.2, I get {{{
nm /opt/local/lib/libkgapi2.2.1.1.dylib | fgrep __ZN6KGAPI27Account14setAccessTokenERK7QString ... T __ZN6KGAPI27Account14setAccessTokenERK7QString }}}
the difference between 't' and 'T' explains everything, AFAIK (but not why both compilers give such different results). -- -- Ticket URL: <https://trac.macports.org/ticket/45331#comment:1> MacPorts <http://www.macports.org/> Ports system for OS X