libgcc 4.8.1 errors on a fresh install macports for Mavericks (OS X 10.9)

[William Capehart]

Ryan:

On any other day, I¹d concur that this isn¹t something you should try at
home or even at your friends house (even if you don¹t like them).  But
unfortunately commenting out the counterpart lines in ³module.c² in the
macport libgcc area creates more errors and I am unsure as to how to
navigate the problem.  I restored the line in vm_types.h as soon as I had
gcc48 build and it passed my tests for c and fortran including OMP and
MPICH once it was installed.  And after the restoration netcdf, those
tests passed also.  (The big test is ncarg but that¹s an extensive build.)

I have found some very old trouble tickets on an error similar to this
such as this one...

http://trac.macports.org/ticket/24541

...but based on the content of the commentary on them I don¹t see any
specific guidance that I can implement.  I am already at the frontiers of
my expertise.
 
Bill



On 11/1/13, 21:33 MDT, "Ryan Schmidt" <ryandesign at macports.org> wrote:

>
>On Nov 1, 2013, at 20:28, William Capehart wrote:
>
>> I went back through the error messages and saw that the conflict was
>>with the module: 
>> 
>> 
>>/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macpo
>>rts.org_release_tarballs_ports_lang_gcc48/libgcc/work/gcc-4.8.1/gcc/fortr
>>an/module.c  
>> 
>> And 
>> 
>>  /usr/include/mach/vm_types.h
>> 
>> I did something that I DON¹T think was the smartest thing and commented
>>out  line 40 of the vm_types file.
>> 
>>  typedef vm_offset_t           pointer_t;
>> 
>> And left the module.c line intact.
>> 
>> This seems to have worked.  libgcc finally completed the build  with no
>>other errors and I am proceeding to build gcc48 and the rest of my
>>working science resources.
>> 
>> I have misgivings as to editing something in /usr/include and am
>>planning restoring line 40 once all my builds are complete .  And
>>additionally I am still apprehensive as to why my system seems to be the
>>only rig around here that has been impacted.
>> 
>> If what I did is a really bad idea.. Uh.. This would be the time to
>>tell me. :-) 
>> 
>> I am reluctant to report this patch on the macports bug tracking site
>>until I have confidence that this working for my critical software.
>
>Certainly you should never edit files in /usr/include.
>
>