__divdi3 undefined

[shahadat]

when i divide a large integer,

msvc works fine.
but djgpp add a symbol __divdi3

sometimes, djgpp dont support large inter
shows warning: integer constant is too large for long type

when i googled it, i find that libgcc is necessary.

can any body help getting around it.

[gerryg400]

when i googled it, i find that libgcc is necessary

It is necessary. You have to build it separately after gcc like this

Code: Select all

make all-gcc
make install-gcc
make all-target-libgcc
make install-target-libgcc

[shahadat]

is there any way except libgcc

[gerryg400]

You could write your own function that does it. Then use that function instead of the '/' operator.

[pcmattman]

May I ask what your reasoning for not wanting to use libgcc is?

If you're using GCC it's fairly logical to use the library (unless there's some circumstance that means you can't) - it has very few dependencies on the OS after all. libgcc also holds target-specific stuff such as the __sync builtins, which come in handy later on.

Of course, if you've weighed up the benefits and downsides to using libgcc and chosen not to use it, ignore me and carry on.

[skyking]

You could of course write a function that does exactly the same, and name it __divdi3. You could also continue doing the same for all the other functions gcc produces implicit calls to. It's not that difficult (except perhaps the RTTI and exception handling and such)...

[Brynet-Inc]

The OpenBSD/NetBSD's C library has "quad" functions that are a compatible replacement for the libgcc functions, but as stated by others you'll have to pull it out.. which isn't overly difficult but still tedious.

http://www.openbsd.org/cgi-bin/cvsweb/s ... libc/quad/
...or as used in their kernel, minus some floating point stuff:
http://www.openbsd.org/cgi-bin/cvsweb/s ... b/libkern/

I do believe that libgcc does other things as well these days, and that the licensing isn't as restrictive as GCC's GPLv3, all versions of GCC newer than 4.2.1 are licensed under that now..

It is silly that GCC likes to provide replacement functions which it believes are more optimized, there are flags to disable this so you can provide your own.. to prevent potentially tainting your kernel.

P.S: Don't use djggp, build a cross compiler.

Good luck.

[Owen]

It is silly that GCC likes to provide replacement functions which it believes are more optimized, there are flags to disable this so you can provide your own.. to prevent potentially tainting your kernel.

They are more optimized; it often does constant folding into them, and there is no call/ret or calling convention overhead. As for tainting... Your program would only be tainted if GCC copied a substantiative amount of itself into it; it doesn't. The FSF even has an FAQ on the GPL to this effect

P.S: Don't use djggp, build a cross compiler.

Agreed.

[skyking]

It is silly that GCC likes to provide replacement functions which it believes are more optimized, there are flags to disable this so you can provide your own.. to prevent potentially tainting your kernel.

They are more optimized; it often does constant folding into them, and there is no call/ret or calling convention overhead. As for tainting... Your program would only be tainted if GCC copied a substantiative amount of itself into it; it doesn't. The FSF even has an FAQ on the GPL to this effect

However when you link your program you're linking it with libgcc (statically, so you actually include it in your final code). So you should take the license of libgcc into account which means the license for the source code that was used to produce it.

[Owen]

However when you link your program you're linking it with libgcc (statically, so you actually include it in your final code). So you should take the license of libgcc into account which means the license for the source code that was used to produce it.

Brynet was referring to the GCC intrinsics, not libgcc. libgcc is under a special license which you can statically link without tainting your code.