Problem with gcc4.7 and call_once

David Barto DBarto at visionpro.com
Thu Aug 8 12:58:08 PDT 2013


It appears that the following is missing from the configuration for libstdc++.

--enable-libstdcxx-threads
Enable C++11 threads support. If not explicitly specified, the configure process enables it if possible. It defaults to 'off' on Solaris 9, where it would break symbol versioning. This option can change the library ABI.

Yes, it changes the ABI, however for std::call_once to work, I think it is required. I don't think that the configuration process is setting it by default.

Any idea how to add this to the configuration from the install line?

sudo port install gcc48 +universal --enable-libstdcxx-threads --enable-fully-dynamic-string

Didn't work.

Neither did
sudo port install gcc48 +universal +thread +fully-dynamic-string

The enable-fully-dynamic-string was a test just to make sure that I could quickly see the configuration change.

Is there some file I can modify that will force these changes into the system?

	David


On Aug 8, 2013, at 8:52 AM, Jeremy Huddleston Sequoia <jeremyhu at macports.org> wrote:

> 
> On Aug 8, 2013, at 8:43, David Barto <DBarto at visionpro.com> wrote:
> 
>> The size of the version compiled with 4.8:
>> 2864 -rwxr-xr-x  1 root  wheel  1463728 Aug  8 07:49 libstdc++.6.dylib
>> 
>> The size of the version in /opt/local/lib:
>> 
>> 559_ ls /opt/local/lib/libstdc++.6.dylib 
>> 6344 -rwxr-xr-x  1 root  admin  3245696 Jul  1 10:14 /opt/local/lib/libstdc++.6.dylib
> 
>> So they are different.
> 
> Is one +universal and the other not?  Does one have debug symbols and the other not?
> 
>> I've put  /opt/local/lib/libstdc++.6.dylib back so that won't be a problem the 2nd time around. However I'll try to snarf the built one to see what happens with it.
>> 
>> And I'll open the bug with the gcc group.
>> 
>> Thanks,
>> 
>> 	David
>> 
>> On Aug 8, 2013, at 8:18 AM, Jeremy Huddleston Sequoia <jeremyhu at macports.org>
>> wrote:
>> 
>>> 
>>> On Aug 8, 2013, at 8:04, David Barto <DBarto at visionpro.com> wrote:
>>> 
>>>> Interesting result of the build of libstdcxx
>>>> 
>>>> gcc 4.8 rebuilt because I removed the /opt/local/lib/libstdc++.6.dylib.
>>> 
>>> ...
>>> 
>>>> When complete however /opt/local/lib/gcc48 has a symbolic link to /opt/local/lib/libstdc++.6.dylib
>>> 
>>> Yes, that's how it's supposed to be.
>>> 
>>>> which is NOT the version just built.
>>> 
>>> Do you have evidence of this?  It should be the same since it's built from the same sources in the same method and then just installed at the other location.
>>> 
>>>> In fact since the file ' /opt/local/lib/libstdc++.6.dylib' doesn't exist, the port package started the build over again. This seems reasonable.
>>>> 
>>>> However since the file that gets built is not installed, this appears to be the problem related to the std::call_once issue.
>>> 
>>> I doubt it.
>>> 
>>>> Any help on getting the port to install the proper file?
>>> 
>>> It is installing the proper file as the libstdcxx subport.
>>> 
>>> Please file this bug with gnu.org and feel free to provide my analysis.  As it is GPL3, I won't be looking at their source to figure out what went wrong.  I did verify that it is still an issue with gcc-4.9's libstdcxx, and you've already mentioned it was an issue with gcc-4.7, so it's not a recent regression.
>>> 
>>> --Jeremy
>>> 
>> 
> 



More information about the macports-users mailing list