This is the mail archive of the
cygwin@sourceware.cygnus.com
mailing list for the Cygwin project.
Re: ld or gcc failing?
- To: cygwin cygwin <cygwin at sourceware dot cygnus dot com>
- Subject: Re: ld or gcc failing?
- From: Richard <hicklinr at mcd dot alcatel dot be>
- Date: Mon, 27 Sep 1999 21:56:33 +0200
- References: <199909271924.OAA11550@mercury.xraylith.wisc.edu>
> Richard <hicklinr@mcd.alcatel.be> writes:
> > I must ask: what is relocatable output actually for (that can't be provided by
> > archives)?
> > (sorry: this is now off topic).
> Essentially -r creates an executable of sorts that contains the relocation
> information so that you can use it in subsequent linking. It also does not
> lay out the common symbols, and does not complain if there are undefined
> symbols during this relocatable link.
> More confused yet ;-?
I certainly am! What could be the purpose of this?
I'm particularly interested because I came across the 16-bit 'file truncated'
problem, and thought I'd solved it by using archives. But then the software didn't
work: modules (it was CHILL) that were to be swapped into context were just not
there - though 'objdump' showed their entry points. I tried this on Solaris SPARC
too (where there was no relocatable size problem) - and had the same problem. It
was necessary to link relocatably for some reason. I have not had the time to
learn enough about the product - or CHILL - to attempt to analyse this. The
quickest solution for me is not to let the relocatables get too large (but too many
files and I have a line-length problem) and not to waste time wondering what is
actually going on. It must have something to do with a CHILL peculiarity, but I
have no idea what.
--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com