[MacPorts] #45331: issues with port:libkgapi: case-folding and exported symbols

[MacPorts]

#45331: issues with port:libkgapi: case-folding and exported symbols
-------------------------+--------------------------------
 Reporter:  rjvbertin@…  |      Owner:  macports-tickets@…
     Type:  defect       |     Status:  new
 Priority:  Normal       |  Milestone:
Component:  ports        |    Version:  2.3.1
 Keywords:               |       Port:  libkgapi
-------------------------+--------------------------------
 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>
MacPorts <http://www.macports.org/>
Ports system for OS X