[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:  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