DragonFlyBSD

Bad configure test?
"no .eh_frame_hdr table" shows up in world build too when crt1.o is created.

It seems this crt1.o error happens on i386 only. The x86_64 version is built differently and doesn't produce the error during world build.

This is what I am having to do to keep the i386 port working with current master pkgsrc:

1) As reported in
http://bugs.dragonflybsd.org/issues/2505

i386 master current as of

commit c090922fe69732915227914768a9c4f9190fdece
Date: Mon Feb 11 18:02:07 2013 +0100

libdialog: Increase MAX_LEN to 4096 (bug 2480)

1. make buildkernel

2) I have reverted for my local branches most of

commit 6100d1de78f204e56aabe46c57a31d6a686e8f55
Date: Sun Feb 3 10:12:27 2013 +0100

Promote GCC 4.7 to be the default compiler

and

commit c06d54ec4d64cac02631af7af5668d43d2f6abd1
Date: Tue Feb 5 20:54:06 2013 +0100

Fix some more things related to the switch to gcc47.

3) I am currently testing reverting

commit 54b03ea7a27868387d5f124816d13c48e32ff735
Date: Mon Feb 11 09:00:13 2013 +0100

bsd.cpu.mk: Set gcc47 as default

4) It is possible to build only the kernel with gcc44, something like

1. make CCVER=gcc44 buildkernel

However this configuration when combined with following the latest pkgsrc master makes running modular-xorg with wm's such as openbox, xfce4, or kde4 impossible.

5) After reverting the commits listed above, I had to go back and make replace some combination including

python27
libdrm
MesaLib
modular-xorg-server

After replacing using a default gcc44 system, startx works again for any of openbox, xfce4, or kde4.

I think we need to state clearly what's going on.
The .eh_frame header isn't being created. This affects c++ programs that use exceptions. The likely cause is that crt1.o is built by gcc47 and gcc44 doesn't like it. The probable fix is the have a gcc-44 built crt1.o, e.g. /usr/lib/crt1.44.o.

The error isn't fatal, programs built with this error should work. The configuration script is choking on the unexpected error.

While I am trying to come up with the right fix (I already bricked by i386 system with the first attempt), the better approach is to rebuild all packages with gcc47 (I think). With the latest master, and removing all previous packages, rebuilding will be done with gcc47 unless DRAGONFLY_CCVER?=gcc44 is in the /usr/pkg/etc/mk.conf file.

I'm taking the issue seriously but I can't try again until this weekend and I have to recover the i386 machine first.

:Issue #2511 has been updated by marino.
:
:While I am trying to come up with the right fix (I already bricked by i386 system with the first attempt), the better approach is to rebuild all packages with gcc47 (I think). With the latest master, and removing all previous packages, rebuilding will be done with gcc47 unless DRAGONFLY_CCVER?=gcc44 is in the /usr/pkg/etc/mk.conf file.
:
:I'm taking the issue seriously but I can't try again until this weekend and I have to recover the i386 machine first.
:----------------------------------------

Since we also had to change the floating point frame size to support
    the new FP instructions we have two things now that really would like
    a complete rebuild with 4.7.

I think it would be an excellent time to switch pkgsrc master builds
    to 4.7.

-Matt

Can you update to the latest world, at least to here:
http://gitweb.dragonflybsd.org/dragonfly.git/commitdiff/4a0e0cd7377c45dc21d5c71bcab931b5e5727e74

and try to build cairo again?
Thanks

The good news is that on an i386 system, nothing enabled in /etc/make.conf, no debugging enabled in /usr/pkg/etc/mk.conf, I was able to build cairo with no errors from scratch after completely replacing pkgsrc packages.

The bad news is still on certain systems, even x86_64 ones, the kernel does not build as noted in

http://bugs.dragonflybsd.org/issues/2505

Is there reason to think 2505 and 2511 are related?

2511 is about missing .eh_frame_hdr which I believe is now fixed and thus this bug report can be closed.
If you have additional information about 2505 then post there -- it's not common, nobody sees a pattern yet. I've never seen it.

1. env CCVER=gcc44 bmake replace clean
   allows startx with .xinitrc of
   exec /usr/pkg/bin/startxfce4
   to start up xfce4 as expected.

The current patches now allow programs such as cairo to compile, but it is not clear to me the functionality is as required.

On the other hand, apparently current pkgsrc xulrunner and firefox 18.0.2 only compile with CCVER=gcc47 due to the additional requirement of gcc 4.5 or higher.

it's not clear what you mean by "present patches" and "current patches".
I assume you mean the current state of the master branch.

To be clear, I don't think gcc47 is miscompiling anything.
If a package doesn't work after being compiled with gcc47, then the problem is likely with the package. This is increasingly likely with the old xorg server that pkgsrc has.

BTW - it's news to be that xulrunner and firefox now require at least gcc 4.5. It's good to know that.