This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug other/46695] [4.6 regression] failure to build X from darwin to cris-elf with lto enabled


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46695

--- Comment #2 from Iain Sandoe <iains at gcc dot gnu.org> 2010-11-29 23:45:00 UTC ---
(In reply to comment #1)
> (In reply to comment #0)
> 
> > /bin/sh ./libtool --tag=CC   --mode=link /GCC/current/bin/gcc-4.6trunk -Wall
> > -Werror -g -O2 -no-undefined
> > Undefined symbols:
> >   "_environ", referenced from:
> >       _environ$non_lazy_ptr in libiberty.a(pex-unix.o)
> >       _environ$non_lazy_ptr in libiberty.a(xmalloc.o)
> > ld: symbol(s) not found

> You're passing -no_undefined and want the library to build allowing undefined
> symbols?

not I, 
the addition of -no-undefined was from the Dave K. who needs it to get a .dll
to build
- without that change, everything is hunky-dory with libtool defaults.
(Dave also has a patch that makes the addition conditional on the *win*
target).

> I'm not sure about that. It may be better to patch libiberty to # include
> <crt_externs.h> and use _NSGetEnviron() instead?

possibly - I guess that would be a potential solution if the build system
requires that there are no symbols resolved at load-time.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]