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 <[email protected]>
wrote:
>
> On Aug 8, 2013, at 8:43, David Barto <[email protected]> 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 <[email protected]>
>> wrote:
>>
>>>
>>> On Aug 8, 2013, at 8:04, David Barto <[email protected]> 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
>>>
>>
>
_______________________________________________
macports-users mailing list
[email protected]
https://lists.macosforge.org/mailman/listinfo/macports-users
