[MacPorts] #36719: gcc47: static c++ standard library (libstdc++.a) not built

[MacPorts]

#36719: gcc47: static c++ standard library (libstdc++.a) not built
---------------------+------------------------
  Reporter:  bach@…  |      Owner:  jeremyhu@…
      Type:  defect  |     Status:  assigned
  Priority:  Normal  |  Milestone:
 Component:  ports   |    Version:  2.1.2
Resolution:          |   Keywords:
      Port:  gcc47   |
---------------------+------------------------

Comment (by jeremyhu@…):

 Replying to [comment:4 bach@…]:
 > Replying to [comment:3 jeremyhu@…]:
 > > What makes you think you need this?
 >
 > I'm the author of a scientific command line software
 (http://sourceforge.net/projects/mira-assembler/) which is a royal pain to
 get all needed components for (because some are pretty recent and not
 installed everywhere), be it for compile time or for for run-time: gcc >=
 4.6, BOOST >= 1.49, zlib >=1.27, google perftools and a couple of others.
 >
 > Users are often biologists with minimal computer skills, often without
 installation / root rights on the corresponding machines which in turn
 might be old installations >=5 years lacking needed libraries. Being able
 to provide people with a single binary they can drop even into their home
 directory without messing with the system (or environment variables like
 DYLD_*, LD_*) turned out over the years to be the simplest solution with
 the least hurdles for them and the least amount of hand holding support by
 me.

 Yeah, I can understand that, but it should be just as straight forward to
 give them a bundle.

 > Main development and run environments of the software is general Unix
 (Linux main, but also Solaris) and the build system is autotools +
 libtools. If there is a **simple** way on Mac to provide the software I am
 willing to try and adapt the build environment, but prime directive is
 that it needs to integrate with autotools/libtools and be easy for the
 user (as described above).

 I don't see why that would be a problem here.

 > [[br]]
 > > Yeah, I thought about providing it, but that will lead to more bugs
 than it fixes.
 >
 > What kind of bugs would these be? I am aware of some ABI hickups in the
 4.7 line (slist most notably) but would be interested to learn what other
 problems could arise.
 >
 > Would switching back to gcc 4.6 help, is a static libstdc++ present
 there?

 The main reason we did this was to unify the libstdc++ offered out of
 MacPorts to avoid conflicts when users mixed binaries built with different
 compilers.  Previously, if you built an executable with code that was from
 gcc46 and gcc45, there would be issues as objects crossed between the C++
 runtimes of those two compilers.  Now, there is one C++ runtime shared by
 all the gcc4X compilers.

 It could be problematic if a library statically linked against libstdc++
 and the executable using that library linked against a
 different/incompatible libstdc++.

 As you're doing this just for your end executable, that should be safe,
 but I worry about it being misused elsewhere.

 You can "fix" this issue for yourself by editing the gcc47 Portfile to not
 delete libstdc++.a in its post-destroot phase.  ie change this:
 {{{
 eval file delete [glob ${destroot}${prefix}/lib/*{a,py}]
 }}}
 to this:
 {{{
 eval file delete [glob ${destroot}${prefix}/lib/*py]
 }}}

-- 
Ticket URL: <https://trac.macports.org/ticket/36719#comment:5>
MacPorts <http://www.macports.org/>
Ports system for Mac OS