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" <[email protected]> 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. > > _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
