On Wed, 2012-07-25 12:24:03 +0200, Jordi Guillaumes i Pons <[email protected]> wrote: > I've got a basic idea about which is the problem with ld. It's > related to LIBPATH. For some reason it puts the contents of LIBPATH > in the generated script: > > /* Default linker script, for normal executables */ > OUTPUT_FORMAT("a.out-pdp11", "a.out-pdp11", > "a.out-pdp11") > OUTPUT_ARCH(pdp11) > SEARCH_DIR("/usr/local/pdp11-aout/lib"); > /opt/orahome/tuxedo10gR3/lib:/usr/lib/jvm/java-6-sun/lib/i386/server:/usr/lib/jvm/java-6-sun/jre/bin:/opt/cobol-it/lib: > PROVIDE (__stack = 0); > SECTIONS
Oh... Not so funny. (I mean the "orahome" part, not the inclusion of
$LIBPATH.) Some time ago, I did do OCI hacking. That was totally k3w1
and fun. Not. I've rarely seen an API interface *that* bad designed
and *that* hard to use.
Looking at the generating script, it works as designed. LIBPATH
shouldn't be set while configure'ing and building binutils and gcc.
Does GCC now work for you, too?
> I understand it should not even try to use the native LIBPATH in a
> cross-build environment. Actually, it looks like some bug in the
> genscripts.sh script, since it just spews $LIBPATH without proper
> "bracketing" (ie, using SEARCH_DIR($LIBPATH)).
Judging from the comments, it works as designed. However, it would be
nice if ./configure or make would catch this.
> I've manually edited the generated scripts and the epdp11.c source
> file and I've rebuilt binutils. Now it works OK. I'll try to file a
> bug report about this.
I'm waiting for a success report for GCC from you :)
MfG, JBG
--
Jan-Benedict Glaw [email protected] +49-172-7608481
Signature of: http://www.chiark.greenend.org.uk/~sgtatham/bugs.html
the second :
signature.asc
Description: Digital signature
_______________________________________________ Simh mailing list [email protected] http://mailman.trailing-edge.com/mailman/listinfo/simh
