Both are compiled/configured the same way, +universal, with whatever debug
symbols from a standard install.
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
