I would like to build a set of universal binaries with MacPorts GCC 4.7.2
(universal), which link in a static C++ standard library.
I would like to do this to see if this will fix errors my end users are seeing
with unlinked objects from the C++ standard library, which are referenced in
code compiled with MacPorts GCC 4.7.2 (universal) but which apparently are not
part of the C++ standard library on a stock installation of (for instance) Mac
OS X 10.8.2.
For example, some OS X users see the following error:
------
$ myBinary
dyld: lazy symbol binding failed: Symbol not found:
__ZNSt8__detail15_List_node_base7_M_hookEPS0_
Referenced from: /usr/local/bin/myBinary
Expected in: /usr/lib/libstdc++.6.dylib
dyld: Symbol not found: __ZNSt8__detail15_List_node_base7_M_hookEPS0_
Referenced from: /usr/local/bin/myBinary
Expected in: /usr/lib/libstdc++.6.dylib
Trace/BPT trap: 5
$ nm myBinary | grep __ZNSt8__detail15_List_node_base7_M_hookEPS0_
U __ZNSt8__detail15_List_node_base7_M_hookEPS0_
------
I added the -static-libstdc++ flag before compilation, but the binaries do not
include the static library and instead appear to continue linking to dynamic
equivalents:
------
$ otool -L /usr/local/bin/myBinary
/usr/local/bin/myBinary:
/usr/lib/libbz2.1.0.dylib (compatibility version 1.0.0, current version
1.0.5)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version
1.2.5)
/opt/local/lib/libstdc++.6.dylib (compatibility version 7.0.0, current
version 7.17.0)
/usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version
1669.0.0)
/opt/local/lib/gcc47/libgcc_s.1.dylib (compatibility version 1.0.0,
current version 1.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version
169.3.0)
------
Distributing MacPorts GCC 4.7.2 (universal) with my pre-built binaries does not
seem like a realistic option. To keep complexity and distribution sizes down, I
would like to try to distribute binaries which just include the static library,
if that is required to address these errors.
It does not appear there is a libstdc++.a file in /opt/local/lib where I might
think it would be. During the build process of the MacPorts distribution of GCC
4.7.2 (universal) the static library might be deleted, which would explain why
it is not included in binaries that try to link it.
I am looking into editing the following line in the GCC 4.7.2 (universal)
Portfile to prevent the deletion of the static library during the build step of
that port:
------
eval file delete [glob ${destroot}${prefix}/lib/*{a,py}]
------
Is it correct that changing this to:
------
eval file delete [glob ${destroot}${prefix}/lib/*{py}]
------
...is sufficient prevent the deletion of the static library?
Assuming that is true, what commands would I run after editing this Portfile to
rebuild GCC 4.7.2 (universal) and recover the static library?
I read through Chapter 4 of the MacPorts Guide:
http://guide.macports.org/#development
It explains how to create a new Portfile, but it is not clear to me from that
step how I would be able to rebuild an existing port from a minor modification
to an existing Portfile.
Does anyone have tips on the procedure involved for rebuilding a port from a
modified Portfile, or can point me to the section of the documentation which
might outline this process in more detail?
Thanks in advance for any assistance.
Regards,
Alex
_______________________________________________
macports-dev mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-dev
