Issue building

John Marino
Tue Jan 11 16:36:00 GMT 2011

Ian Lance Taylor wrote:
> Note that if you are using a linker which supports the --eh-frame-hdr
> option, and if your libc provides the dl_iterate_phdr function, and if
> the gcc configure script figures those things out, then exceptions will
> correctly propagate across shared libraries even if you don't use
>  That approach is also more efficient and should be used if
> possible, so may not be an issue for you.

That's affirmative for the linker, but I know libc doesn't have 
dl_iterate_phdr.  Somebody even gave me a patch to add that 
functionality a few months ago, but they never submitted it to the 
DragonFly devs.  As an aside, I might follow that up to take advantage 
for future releases of DragonFly, but for the present it appears that 
still need

> This could indeed be the problem.  Did you use --disable-bootstrap when
> you ran configure?  When bootstrapping, this is supposed work due to the
> setting of LD_LIBRARY_PATH in the top level Makefile before building
> adalib.  Specifically, these lines:
> 	$(RPATH_ENVVAR)=`echo "$(TARGET_LIB_PATH)$$$(RPATH_ENVVAR)" | sed 's,::*,:,g;s,^:*,,;s,:*$$,,'`; export $(RPATH_ENVVAR); \
> Ideally should be found via HOST_LIB_PATH_gcc.
> (If you used --disable-bootstrap, then you are more or less responsible
> for dealing with this yourself.)

Yes, that's exactly what I'm using.  Sounds like the solution is either 
remove that configuration item or deal with this paths myself as you 
mentioned.  This information points in me in the right direction.

> You'll have to ask the ports people.  In Debian or RPM packaging,
> is only installed by the core gcc package.

Yeah, I don't think that kind of restriction is in place for the BSDs. 
I was thinking there might be some common configuration that results in 
a unique file location so they don't step on each other, but it sounds 
like there's only one spot for library.

Thanks Ian!


More information about the Gcc-help mailing list