This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug other/46695] [4.6 regression] failure to build X from darwin to cris-elf with lto enabled
- From: "iains at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Mon, 29 Nov 2010 23:45:02 +0000
- Subject: [Bug other/46695] [4.6 regression] failure to build X from darwin to cris-elf with lto enabled
- Auto-submitted: auto-generated
- References: <bug-46695-4@http.gcc.gnu.org/bugzilla/>
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.