[Fwd: Where are _modsi3.c and/or _modsi3.o?]

[Christopher Bahns <chris at bahns dot com>]

Thanks for the info. After much analysis I finally figured out my problem, but
could still use a bit more help. My m68k cross compiler was linking with the wrong
library. It appears that when I build the cross compiler, it makes several versions
of libgcc.a:

/gcc-m68k/lib/gcc-lib/m68k-coff/2.95.2/
/gcc-m68k/lib/gcc-lib/m68k-coff/2.95.2/m68000/
/gcc-m68k/lib/gcc-lib/m68k-coff/2.95.2/m5200/
/gcc-m68k/lib/gcc-lib/m68k-coff/2.95.2/mcpu32/

By default it links with the first one, in the m68k-coff "root" directory I
suppose. If I delete this file and do one of the following, the mod operator works:

1. Make a symbolic link for libgcc.a in ".../2.95.2/" to
".../2.95.2/m68000/libgcc.a".
- or -
2. Add the library path ".../2.95.2/m68000" in my makefile (with the -L option) or
with a SEARCH_DIR() command in the linker command script.

My question now is:
How can I link to the libgcc.a in the m68000 subdirectory without deleting the one
in the parent directory?

I tried #2 above without deleting the default libgcc.a and that did not work. I'd
prefer not to mess with the files that are installed for the compiler if I can help
it. The way I'm doing it I'll have to remember each time I rebuild or reinstall the
compiler to make this little change before I can actually build something. I'm
trying to get this stuff together for other people to install and use on their own
machines, so it would be nice to avoid these complications and minimize the chance
for error. If I can do everything in the makefile and linker script that would be
nice.

Thanks a for any help
Chris

Jeff Bevis wrote:

> Hi Christopher,
>
> I am glad to help if I can.  Porting our software from a Diab-compiled
> environment into one which is gcc-compiled has given me a new level of
> appreciation for help in whatever form it arrives.  :^)
>
> The situation I am facing is more of a problem with the GPL than actual
> coding, but it is both.  I can't release the source code to our product
> publicly;  it's not an option.  We have a custom OS, which requires us to
> build our own libraries (it's all done with shared modules, kind of like
> DLLs) for things like FP math (sadly, we have no FPU in our system).   The
> gnu compiler generates lots of references to 64-bit math functions and so
> forth, and I guess I just haven't found the definitive reference on this
> yet.  I don't know the complete set of functions. That was part 1; part 2
> of the problem is that using the gnu library source to build our libraries
> (the FP math again) appears to violate the GPL, as we would not be able to
> release source.  Looking for FP math in newlib, I have found nothing.  So
> does this mean we have to write FP math from scratch?  EEEeeeek!
>
> So we're not really experiencing bugs, per se, as much as we're having
> trouble understanding what functions are required, what their prototypes
> are, and so forth.  And then of course that issue of legality with GPL.
>
> At 08:24 PM 6/24/00 -0500, you wrote:
> >About the assembly listing options, I don't think I want to do it exactly
> >the way
> >you say because if I invoke the assembler directly it does not use all of the
> >default paths. Invoking the assembler/linker through 'gcc' causes it to
> >include
> >all of the necessary paths. Why it works this way I'm not sure. Russ Shaw
> >recommended calling gcc with '-Wa,-aldh', which is probably what I want to do.
> >Anyway, I'll try it and see.
>
> Yeah, that sounds right.  I prefer doing it separately in our setup, but
> you can pass options on to the assembler via the compiler, too.  I'm not
> sure of the options, but that looks right.  Beware the huge amount of debug
> that goes into your .o files now, you'll have to have the linker remove
> that in the output file unless you can tolerate a HUGE file.  :^)
begin:vcard 
n:Bahns;Christopher
tel;home:812-342-4714
tel;work:812-342-4714
x-mozilla-html:FALSE
adr:;;;;;;
version:2.1
email;internet:chris@bahns.com
fn:Christopher Bahns
end:vcard

------
Want more information?  See the CrossGCC FAQ, http://www.objsw.com/CrossGCC/
Want to unsubscribe? Send a note to crossgcc-unsubscribe@sourceware.cygnus.com