libgcc fails to build on SnowLeopard: error: 'getsectiondata' was not declared in this scope

[rmottola (Riccardo)]

gcc48 built fine on 10.6 on a 64bit CPU, but I need Universal since I need to compile 32bit binaries (port of TenFourFox to intel) and gcc48 is suggested as in ​https://github.com/classilla/tenfourfox/wiki/HowToBuildFPR

On the console I see:

--->  Building libgcc
Error: Failed to build libgcc: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/main.log for details.
Error: Follow https://guide.macports.org/#project.tickets to report a bug.
Error: Processing of port gcc48 failed

I wonder if it is correct that it is trying to build libgcc from gcc7?

The log says build of libgcc fails:

:debug:build could not read "/opt/local/share/info/mpc.info": no such file or directory

[rmottola (Riccardo)]

I tried building gcc6 universal and it fails in the same way. Is the issue actually in libgcc or is the issue that libgcc from gcc7 is pulled in?

[ryandesign (Ryan Carsten Schmidt)]

Replying to rmottola:

I wonder if it is correct that it is trying to build libgcc from gcc7?

Yes, that is correct.

The log says build of libgcc fails:

:debug:build could not read "/opt/local/share/info/mpc.info": no such file or directory

That is probably irrelevant. Please attach the entire main.log file, compressed if large.

[rmottola (Riccardo)]

gcc48-buildlog

[kencu (Ken)]

libgcc builds universal for me without any trouble on 10.6.8:

$ port -v installed | grep libgcc
  libgcc @6.2.0_0+universal platform='darwin 10' archs='i386 x86_64' date='2017-01-01T21:20:24-0800'
  libgcc @6.4.0_0+universal platform='darwin 10' archs='i386 x86_64' date='2017-08-19T16:58:03-0700'
  libgcc @7.2.0_1+universal (active) platform='darwin 10' archs='i386 x86_64' date='2017-10-21T18:27:37-0700'
  libgcc6 @6.4.0_1+universal (active) platform='darwin 10' archs='i386 x86_64' date='2017-11-12T11:36:11-0800'

and you can have almost any version of gcc you want on 10.6.8 at preesnt:

$ port -v installed | grep gcc
  gcc5 @5.5.0_0 (active) platform='darwin 10' archs='x86_64' date='2017-10-21T22:30:22-0700'
  gcc6 @6.4.0_0 (active) platform='darwin 10' archs='x86_64' date='2017-08-19T18:28:19-0700'
  gcc7 @7.2.0_0 (active) platform='darwin 10' archs='x86_64' date='2017-10-02T23:22:13-0700'
  gcc45 @4.5.4_13 (active) platform='darwin 10' archs='x86_64' date='2017-11-04T01:24:52-0700'
  gcc48 @4.8.5_1 platform='darwin 10' archs='x86_64' date='2017-03-08T20:39:22-0800'

I haven't built gcc itself as universal for a while.

I really hope you can get TenFourFox working for Intel -- it would be great to have it on 10.6.8. Also you might be interested in checking out epiphany and webkit2-gtk which work quite well on 10.6.8, and I am just in the process of updating them to the latest versions which would give 10.6.8 a very modern browser to use as well.

Good luck!

[kencu (Ken)]

just rebuilt it:

$ port -v installed gcc48
The following ports are currently installed:
   gcc48 @4.8.5_2+universal (active) platform='darwin 10' archs='i386 x86_64' date='2017-11-12T12:48:38-0800'

[kencu (Ken)]

I have my default compiler set to clang-3.9, and I use that to build everything on MacPorts. It works spectacularly well for me, and I have not been inclined to change it for some time now. So, you could try that quite easily. Other compilers might well work, and we should figure out why the default build is not working for you. But if you're in a "get it done" mood, clang-3.9 definitely worked for me.

Install clang-3.9 (sudo port -v install clang-3.9 should do it) and then sudo port -v install gcc48 +universal configure.compiler=macports-clang-3.9.

[rmottola (Riccardo)]

TenFourFox for for Intel will be a small challenge, help appreciated... but off-topic this bug. Cameron explicitely advises for gcc48, later gcc sometimes works, clang not.

I tried separately

sudo port install libgcc +universal

And this fails... so the issue is actually libgcc and not gcc itself. Should I rename/recategorize this ticket to libgcc7?

[rmottola (Riccardo)]

I notice I can't change this to a libgcc bug, but my problem is clearly there since triggered by that single install.

Did my log give any clues?

[kencu (Ken)]

Given that I just built it +universal with clang-3.9 and it worked fine, you could try building it with clang-3.9 and see if that works for you as well. Obviously there is something to be sorted out somewhere, but that's a trivially easy first step for you.

sudo port -v install clang-3.9

then

sudo port -v install gcc48 +universal configure.compiler=macports-clang-3.9 will do it.

[kencu (Ken)]

One thing I noticed in your log is that you aren't cleaning between attempts to build. In a situation like this, you should

sudo port clean libgcc gcc48

and then try your build again. Not cleaning leaves partially configured builds around and that is nothing but trouble.

just FYI as well, /opt/local/share/info/mpc.info is provided by port: libmpc so you might check to see if that is installed. It is a listed dependency for libgcc, so it should be.

[rmottola (Riccardo)]

That log was from my second attempt of build, which I just reissued. I did then clean gcc58 and libgcc and then install universal of libgcc, but it still fails.

I then did as Ken suggested. A new clean, installed clang-3.9 However, the build of libgcc fails with the error below.

org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/gcc-7.2.0/libsanitizer/asan/asan_mac.cc
:info:build libtool: compile:  /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/build/./gcc/xgcc -shared-libgcc -B/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/build/./gcc -nostdinc++ -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/build/x86_64-apple-darwin10/libstdc++-v3/src -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/build/x86_64-apple-darwin10/libstdc++-v3/src/.libs -L/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/build/x86_64-apple-darwin10/libstdc++-v3/libsupc++/.libs -B/opt/local/x86_64-apple-darwin10/bin/ -B/opt/local/x86_64-apple-darwin10/lib/ -isystem /opt/local/x86_64-apple-darwin10/include -isystem /opt/local/x86_64-apple-darwin10/sys-include -D_GNU_SOURCE -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -DASAN_HAS_EXCEPTIONS=1 -DASAN_NEEDS_SEGV=1 -DCAN_SANITIZE_UB=0 -DMAC_INTERPOSE_FUNCTIONS -DMISSING_BLOCKS_SUPPORT -I. -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/gcc-7.2.0/libsanitizer/asan -I.. -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/gcc-7.2.0/libsanitizer/include -I /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/gcc-7.2.0/libsanitizer -Wall -W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC -fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables -fvisibility=hidden -Wno-variadic-macros -fno-ipa-icf -I../../libstdc++-v3/include -I../../libstdc++-v3/include/x86_64-apple-darwin10 -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/gcc-7.2.0/libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11 -g -O2 -pipe -Os -MT asan_mac.lo -MD -MP -MF .deps/asan_mac.Tpo -c /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/gcc-7.2.0/libsanitizer/asan/asan_mac.cc  -fno-common -DPIC -o .libs/asan_mac.o
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/gcc-7.2.0/libsanitizer/asan/asan_mac.cc: In function 'void __asan::AsanApplyToGlobals(__asan::globals_op_fptr, const void*)':
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/gcc-7.2.0/libsanitizer/asan/asan_mac.cc:84:45: error: 'getsectiondata' was not declared in this scope
:info:build    __asan_global *globals = (__asan_global *)getsectiondata(
:info:build                                              ^~~~~~~~~~~~~~
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/gcc-7.2.0/libsanitizer/asan/asan_mac.cc:84:45: note: suggested alternative: 'getsectdata'
:info:build    __asan_global *globals = (__asan_global *)getsectiondata(
:info:build                                              ^~~~~~~~~~~~~~
:info:build                                              getsectdata
:info:build make[4]: *** [asan_mac.lo] Error 1
:info:build make[4]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/build/x86_64-apple-darwin10/libsanitizer/asan'
:info:build make[3]: *** [all-recursive] Error 1
:info:build make[3]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/build/x86_64-apple-darwin10/libsanitizer'
:info:build make[2]: *** [all] Error 2
:info:build make[2]: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/build/x86_64-apple-darwin10/libsanitizer'
:info:build make[1]: *** [all-target-libsanitizer] Error 2

[kencu (Ken)]

I don't see a build log from a clean build attempt yet to look at.

do exactly this:

sudo port clean libgcc
sudo port clean gcc48
sudo port -v install libgcc +universal

and if it fails, please post the log.

[rmottola (Riccardo)]

The above was the error with the clang build, which failed. Now I cleaned and build as you suggested. I attach the build failure

make: Leaving directory `/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/build'
Command failed:  cd "/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/build" && /usr/bin/make -j2 -w bootstrap-lean 
Exit code: 2
Error: Failed to build libgcc: command execution failed
Error: See /opt/local/var/macports/logs/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/main.log for details.

[rmottola (Riccardo)]

libgcc build

[kencu (Ken)]

I think you might possibly be running into something we noticed a few months ago with the linker (ld64) on snow leopard. It is not happening on my machine, but this snowleopard machine I'm on is highly tuned, and highly compatible with newer software (see LibcxxOnOlderSystems if you're interested in that someday).

The discussion about the linker issues was here 53931. I thought we had that resolved.

can you give me the output of port -v installed | grep ld64 please. Here is what I have:

$ port -v installed | grep ld64
  ld64 @2_0+universal-ld64_127-ld64_136-ld64_236-ld64_97 platform='darwin 10' archs='i386 x86_64' date='2016-09-01T23:15:02-0700'
  ld64 @3_0+universal-ld64_127-ld64_236-ld64_97 (active) platform='darwin 10' archs='i386 x86_64' date='2017-08-19T14:34:09-0700'
  ld64-136 @136_9+llvm39-llvm34 platform='darwin 10' archs='x86_64' date='2016-12-21T10:45:57-0800'
  ld64-236 @236.3_7+llvm39-llvm34 (active) platform='darwin 10' archs='x86_64' date='2017-08-19T19:16:27-0700'
  ld64-latest @274.1_1+llvm39+universal-llvm34 platform='darwin 10' archs='i386 x86_64' date='2016-12-21T15:41:59-0800'
  ld64-latest @274.2_1+llvm39+universal-llvm34 (active) platform='darwin 10' archs='i386 x86_64' date='2017-08-19T14:34:08-0700'

The current versions of libgcc builds on the 10.6.8 buildbots in both i386 and in x86_64 architectures. It builds universal on my machine. I'll wind up a VM at home I have and see if it will build +universal.

It might not be a terrible idea to tweak the buildbot to build a +universal version for everyone as well, as it takes forever to build one.

[kencu (Ken)]

Riccardo, can you confirm that you can actually build libgcc NOT universal?

Please try sudo port -v destroot libgcc to confirm that you can get that to completion, at least.

[rmottola (Riccardo)]

Before attempting universal build, I was able to compile gcc48 as 64bit and thus libgcc too (I specified this in tbe initial bug report). So 64bit is fine.

I uninstalled and cleaned before attempting +universal

[kencu (Ken)]

You may not realize that unless you specifically did something out-of-the ordinary like sudo port -v -s install libgcc, then you didn't build it, you downloaded the binary prebuilt from the macports prebuilt packages server.

So at present, we don't know if you can build it. Perhaps you can.

However, if you can't build it at all, then we have a reasonable clue that something is amiss on your system rather than with the libgcc port itself.

[rmottola (Riccardo)]

that is why it was so fast :) Sadly, no, libgcc doesn't build either, although the error is different. Buildlog attached

[rmottola (Riccardo)]

standard 64bit build

[kencu (Ken)]

I let my "reference" 10.6.8 VM run overnight building libgcc +universal, and it failed to build it, just like you. I obtained the same error you did:

/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/gcc-7.2.0/libsanitizer/asan/asan_mac.cc:84:45: error: 'getsectiondata' was not declared in this scope
   __asan_global *globals = (__asan_global *)getsectiondata(
                                             ^~~~~~~~~~~~~~

Now I'm confused, because I just built it on my day-to-day 10.6.8 machine without any trouble, although it is configured slightly differently. The fact that it also builds on the buildbots (although universal was not tried on the buildbots) is interesting.

I have the following installed on that reference VM:

$ port -v installed | grep ld
  ld64 @3_0+ld64_127+universal platform='darwin 10' archs='i386 x86_64' date='2017-10-22T18:23:31-0700'
  ld64 @3_0+ld64_127 (active) platform='darwin 10' archs='x86_64' date='2017-05-10T12:50:27-0700'
  ld64-127 @127.2_14+llvm34+universal platform='darwin 10' archs='i386 x86_64' date='2017-10-22T18:23:29-0700'
  ld64-127 @127.2_14+llvm34 (active) platform='darwin 10' archs='x86_64' date='2017-05-10T12:50:25-0700'
  ld64-236 @236.3_7+llvm34 platform='darwin 10' archs='x86_64' date='2017-05-10T15:43:54-0700'

I _think_ the issue might be in the linker, above. I'll try upgrading to a newer linker (ld64 version) and see what happens.

Here's what I did to upgrade to a newer linker on 10.6.8

sudo port deactivate ld64
sudo port deactivate ld64-127
sudo port install ld64-236
sudo port install ld64 +ld64_236 -ld64_127

I don't know yet if this is the key thing that is needed to fix this build.

I'll let you know how it turns out.

[kencu (Ken)]

I notice on your second (non-universal) build, the triggering error ("error 1") was in fact the same thing:

:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/gcc-7.2.0/libsanitizer/asan/asan_mac.cc:84:45: error: 'getsectiondata' was not declared in this scope
:info:build    __asan_global *globals = (__asan_global *)getsectiondata(
:info:build                                              ^~~~~~~~~~~~~~
:info:build /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/gcc-7.2.0/libsanitizer/asan/asan_mac.cc:84:45: note: suggested alternative: 'getsectdata'
:info:build    __asan_global *globals = (__asan_global *)getsectiondata(
:info:build                                              ^~~~~~~~~~~~~~
:info:build                                              getsectdata
:info:build /bin/sh ./libtool  --tag=CC   --mode=compile /opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/build/./gcc/xgcc -B/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/build/./gcc/ -B/opt/local/x86_64-apple-darwin10/bin/ -B/opt/local/x86_64-apple-darwin10/lib/ -isystem /opt/local/x86_64-apple-darwin10/include -isystem /opt/local/x86_64-apple-darwin10/sys-include    -DHAVE_CONFIG_H -I. -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/gcc-7.2.0/libgfortran  -iquote/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/gcc-7.2.0/libgfortran/io -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/gcc-7.2.0/libgfortran/../gcc -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/gcc-7.2.0/libgfortran/../gcc/config -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/gcc-7.2.0/libgfortran/../libquadmath -I../.././gcc -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/gcc-7.2.0/libgfortran/../libgcc -I../libgcc -I/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/gcc-7.2.0/libgfortran/../libbacktrace -I../libbacktrace -I../libbacktrace  -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -Werror=implicit-function-declaration -Werror=vla -fcx-fortran-rules -ffunction-sections -fdata-sections   -g -O2 -pipe -Os -MT bounds.lo -MD -MP -MF .deps/bounds.Tpo -c -o bounds.lo `test -f 'runtime/bounds.c' || echo '/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc7/libgcc/work/gcc-7.2.0/libgfortran/'`runtime/bounds.c
:info:build make[4]: *** [asan_mac.lo] Error 1

[kencu (Ken)]

The file that implements this seems to be referenced here:

<​https://github.com/llvm-mirror/compiler-rt/blob/master/lib/asan/asan_mac.cc>

[kencu (Ken)]

Another possible cause for this is this commit <​https://github.com/macports/macports-ports/commit/61e9526f91b4603a41251f7f3285cc9d38521838#diff-969dec99a801dec9918fbde6ddf5d442>, wherein parallel building was re-enabled for libgcc builds. That can do weird and unpredictable things to a build.

[kencu (Ken)]

OK. Updating the linker does not fix the build. I've disabled parallel building again, and we'll see if that works.

[kencu (Ken)]

Well, heck. Disabling parallel building didn't work. On my 10.6.8 VM, it doesn't build, with that same getsectiondata error. I am confused now.

[kencu (Ken)]

Building with clang-5.0 on my VM did not succeed. Same error. Something has changed, I suppose. All I can think of doing just now is to disable asan:

configure.args-append --disable-libsanitizer

[kencu (Ken)]

that worked (on my 10.6.8 VM)

$ port -v installed libgcc
The following ports are currently installed:
  libgcc @6.4.0_0 platform='darwin 10' archs='x86_64' date='2017-08-30T13:18:11-0700'
  libgcc @7.2.0_0 platform='darwin 10' archs='x86_64' date='2017-09-09T20:00:21-0700'
  libgcc @7.2.0_1 platform='darwin 10' archs='x86_64' date='2017-10-16T02:45:40-0700'
  libgcc @7.2.0_1+universal (active) platform='darwin 10' archs='i386 x86_64' date='2017-11-19T18:47:26-0800'

So, for the OP: open your libgcc portfile sudo vi `port file libgcc` and paste the following near the other configure args

configure.args-append --disable-libsanitizer

and you should be good to go to build libgcc while we try figure out what happened that it's not building any more, at least on some systems.

[rmottola (Riccardo)]

I am attempting the libsanitizer route. In the meanhile, for Ken: if you are interested in the TenFourFox effort, we should have contact outside this thread. I will set/up a 10.4 intel 32bit machine, to match the corresponding PPC environment and build 32bit natively. Getting 10.6 universal is the "next step" I will continue to setup.

[kencu (Ken)]

Here's a sorta working Portfile for TenFourFox that might be useful to get you started <​https://github.com/kencu/myports/tree/master/www/tenfourfox>. It has not yet built through to completion on my 10.4/PPC system, which I assume will be the easiest to get going, though.

I will warn you, this will be a bit complicated in the end.

[kencu (Ken)]

10.7 build libgcc without any problem. Also +universal.

[kencu (Ken)]

I think snowleopard needs to have libmacho added as a build dependency if it is desired to build asan on 10.6, as per this bit from the libunwind Portfile:

    if {${os.major} < 11} {
        # Snow Leopard's libSystem's libmacho does not contain getsectiondata()

        depends_build-append port:libmacho
        configure.cppflags-append -DUSE_MACPORTS_LIBUNWIND
        configure.ldflags-append -lmacho
    }

[rmottola (Riccardo)]

the Build with

configure.args-append --disable-libsanitizer

of libgcc completed on 10.6.8 universal. I then proceeded to instal libggc48 universal which build libgcc6 which built without any tricks.

[kencu (Ken)]

installing libmacho indeed allows libgcc to build through with libsantizer still active -- but without linking in -lmacho somehow I would imagin that will probably fail when anyone tries to use it, as the symbol is not in libSystem. Who cares about libsanitizer on snow leopard anyway? Perhaps the best thing is to just disable it.

I am not really clear why this error is showing up now and not before, though. Maybe some previous version of dependencies called in libmacho?

[rmottola (Riccardo)]

I don't have ideas about libmacho.

However I tried using the compiled gcc48 and it gives me issues. I have

  gcc48 @4.8.5_2+universal (active) platform='darwin 10' archs='i386 x86_64' date='2017-11-21T04:12:06+0100'
  gcc_select @0.1_8 (active) platform='darwin 10' archs='noarch' date='2017-11-08T23:26:46+0100'
  libgcc @7.2.0_1+universal (active) platform='darwin 10' archs='i386 x86_64' date='2017-11-20T23:16:37+0100'
  libgcc6 @6.4.0_1+universal (active) platform='darwin 10' archs='i386 x86_64' date='2017-11-21T02:31:19+0100'

That says I have now libgcc and gcc48 as "universal" for intel, right? However:

gcc-mp-4.8 -march=pentium-m hello.c 
hello.c:1:0: error: CPU you selected does not support x86-64 instruction set

without specifing the architecture, I get a.out as 64bit.

[kencu (Ken)]

try

gcc-mp-4.8 -m32 hello.c

[rmottola (Riccardo)]

thank you : -m32 works fine with -march=pentium-m so the compiler built with --disable-libsanitizer is confirmed to work.

DO we have news about the "original" issue?

[rmottola (Riccardo)]

An update on this: I was updating ports and the new libgcc failed again, clearly the update removed the --disable-libsanitizer hack. So the "issue" is still open.

I readded it and am trying again, will take some time!

I start to share the idea of Ken that wether we fix the build with libsanitizer or disable it on SL (how do Tiger and Leopard perform?).

[rmottola (Riccardo)]

Just a note: it still happens on current libgcc. During the current portupgrade and updates, build fails.

I don't fully understand. I notice that the 7.3.0 version of libgcc has>

configure.args-append --disable-libsanitizer

perhaps it is not working or gets appended only under certain conditions??

when I compiled 7.2, I had:

                    --disable-libsanitizer \

it worked. I will try with that, but very strange.

[kencu (Ken)]

gcc disables asan on incompatible systems now, and we don't see this any longer