Bug #2511
closed/usr/libexec/binutils222/elf/ld.bfd: error in /usr/lib/crt1.o(.eh_frame); no .eh_frame_hdr table will be created.
0%
Description
Using current master src through:
commit e1dad499f942b88618bab2f62bdd2f7ae9f58209
Date: Thu Feb 7 20:05:52 2013 +0100
games/atc: Fix a logic bug.
- make buildworld && make CCVER=gcc44 buildkernel
and using current pkgsrc, updating graphics/cairo on i386 has in config.log messages such as:
configure:32959: checking for cairo's pthread feature
configure:33070: cc -o conftest -O2 -g -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -pthread -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -L/usr/lib -Wl,-R/usr/lib conftest.c -lrt -lm -lpthread -lrt >&5
/usr/libexec/binutils222/elf/ld.bfd: error in /usr/lib/crt1.o(.eh_frame); no .eh_frame_hdr table will be created.
configure:33070: $? = 0
configure:33189: cc -o conftest -O2 -g -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -pthread -I/usr/pkg/include -I/usr/include -I/usr/pkg/include/freetype2 -L/usr/pkg/lib -Wl,-R/usr/pkg/lib -L/usr/lib -Wl,-R/usr/lib conftest.c -lrt -lm >&5
/usr/libexec/binutils222/elf/ld.bfd: error in /usr/lib/crt1.o(.eh_frame); no .eh_frame_hdr table will be created.
configure:33189: $? = 0
cairo build on i386 seems to not detect pthread and to build one has to set -DCAIRO_NO_MUTEX=1 in CFLAGS.
Attached is the full config.log
Perhaps related, pkgsrc x.org does not appear to function on x86_64 or i386 even using a simple window manager such as openbox, but I have not had time to complete a full rebuild due to massive changes in pkgsrc versions the past week.
Files
Updated by marino almost 12 years ago
Bad configure test?
"no .eh_frame_hdr table" shows up in world build too when crt1.o is created.
Updated by marino almost 12 years ago
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.
Updated by davshao almost 12 years ago
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)
fails
- 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
- 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.
Updated by marino almost 12 years ago
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.
Updated by dillon almost 12 years ago
: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
Updated by marino almost 12 years ago
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
Updated by davshao almost 12 years ago
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
Updated by marino almost 12 years ago
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.
Updated by davshao almost 12 years ago
- 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.
Updated by marino almost 12 years ago
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.
Updated by marino almost 12 years ago
- Status changed from New to Closed
Please reopen if it is felt issue is not yet resolved.