What binutils version are you using?  do ld --version.  This might be a bug in binutils really.

(In reply to comment #1)
> What binutils version are you using?  do ld --version.  This might be a bug in
> binutils really.

it is recent, I think:
> ld -v
GNU ld (GNU Binutils; openSUSE 11.0) 2.18.50.20080409-11.1

Jakub,

the error message I get below is new with gcc 4.5, and is still present as of revision 148276 (20090608). Is there any info I can provide (e.g. attach the object file?) that could help in getting this resolved as either a gcc or a binutils issue.

Joost 

Start with trying newer binutils.

(In reply to comment #4)
> Start with trying newer binutils.
same error with :

/data03/vondele/binutils-2.19.1/build/bin/ld: error in /data03/vondele/clean/cp2k/src/../lib/Linux-x86-64-gfortran/sdbg/libcp2k_lib.a(ep_methods.o)(.eh_frame); no .eh_frame_hdr table will be created.
make[2]: Leaving directory `/data03/vondele/clean/cp2k/obj/Linux-x86-64-gfortran/sdbg'
make[1]: Leaving directory `/data03/vondele/clean/cp2k/src'
vondele@pcihopt3:/data03/vondele/clean/cp2k/src> ld -v
GNU ld (GNU Binutils) 2.19.1
vondele@pcihopt3:/data03/vondele/clean/cp2k/src> gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /data03/vondele/gcc_trunk/gcc/configure --disable-bootstrap --prefix=/data03/vondele/gcc_trunk/build --enable-languages=c,c++,fortran --disable-multilib --with-ppl=/data03/vondele/gcc_trunk/build/ --with-cloog=/data03/vondele/gcc_trunk/build/
Thread model: posix
gcc version 4.5.0 20090608 (experimental) [trunk revision 148276] (GCC)

Couldn't reproduce (just built cp2k on x86_64-linux with trunk gfortran and
.eh_frame_hdr has been created just fine).  I'm using binutils 2.19.51.0.2.

Anyway, you should probably just tar up the .a library and other things you are linking together and with that report it in binutils bugzilla.

(In reply to comment #6)
> Couldn't reproduce (just built cp2k on x86_64-linux with trunk gfortran and
> .eh_frame_hdr has been created just fine).  I'm using binutils 2.19.51.0.2.
> 
> Anyway, you should probably just tar up the .a library and other things you are
> linking together and with that report it in binutils bugzilla.
> 

It seems to depend on the compilation options as well. The sopt compile (in my case :
FCFLAGS  = -O2 -ffast-math -funroll-loops -ftree-vectorize -march=native -ffree-form $(DFLAGS) -I$(GFORTRAN_INC)
goes fine, while a -O0 compile (sdbg compile with flags:
-O0 -g -ffree-form $(DFLAGS) -I$(GFORTRAN_INC) -fbounds-check
)
produces warnings. In fact, the number of errors depends on the precise options. With -fbounds-check present, there are more errors than without the flag. Any 
chance you could try that ?
make distclean
make ARCH=... VESION=sdbg

(In reply to comment #6)
> Anyway, you should probably just tar up the .a library and other things you are
> linking together and with that report it in binutils bugzilla.
> 

filed this PR for binutiles, 

http://sourceware.org/bugzilla/show_bug.cgi?id=10255

and made the object files/libraries available (with README)

http://www.pci.uzh.ch/vandevondele/tmp/PR40332.tgz

Since the corresponding binutils bug is fixed, should this PR be closed ?

(In reply to comment #9)
> Since the corresponding binutils bug is fixed, should this PR be closed ?

We ran into this bug recently, running tests against a GCC (4.5 precursor)
snapshot.  Discussion here:
http://gcc.gnu.org/ml/gcc/2010-01/msg00332.html

after the previous comment, marking this as a regression, confirm it, and set P1 as suggest by Ian on the list. 

Only RMs may change regression priority.

I reluctantly agree with Ian's comment in:

http://gcc.gnu.org/ml/gcc/2010-01/msg00332.html

that:

"I think it would be troubling if a gcc release required a very new
binutils release on a popular platform like x86_64."

I actually think we should be unsympathetic to this kind of mixing of components.  GCC is the only major compiler that does not consider the compiler, assembler, and linker to be a "single unit".  We've made the problem harder for ourselves than it needs to be, for the dubious benefit that users can download a new GCC release without having to get a new assembler and linker.

However, even though I think our policy is counterproductive, it is in fact our policy.  We shouldn't change the policy by accident; we should change it through conscious decision.  Until then, we should indeed to as Ian suggests and:

"modify
the configure test for gcc_cv_as_cfi_directive to avoid the problem
when using an older binutils"

Created attachment 19923 [details]
patch

Subject: Bug 40332

Author: jason
Date: Sat Feb 20 03:50:13 2010
New Revision: 156918

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156918
Log:
	PR target/40332
	* configure.ac (gcc_cv_as_cfi_advance_working): Check 32-bit advance.
	* configure: Likewise.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/configure
    trunk/gcc/configure.ac

Fixed.