[MacPorts] #45331: issues with port:libkgapi: case-folding and exported symbols
MacPorts
noreply at macports.org
Fri Oct 10 17:39:25 PDT 2014
#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
More information about the macports-tickets
mailing list