除3，mod 3... for arm cross-compile

article from:
http://osdir.com/ml/debian.devel.gcc/2002-08/msg00071.html
在cros compile時意外發現的問題
當compile share libraries *.so時有用 '%3' (ex 100 % 3)會出現問題
這是在run time時會有unresolved symbol '__modsi3' ，但不會在linking時warnning
but if compiled as ELF executable file, it is work fine.
同樣地，好像除3也會有__divsi3的問題(沒驗證)

這似乎和.hidden section有關，以下文章可供參考

Okay, HJ Lu has helped resolve the remaining issues in our transition to
building glibc under gcc 3.2. There have been several critical binutils
bugs fixed related to this issue that Chris Chimelis will get into the
next binutils package. The remaining portion of this is the attached patch
from Franz Sirl that will be going into glibc-2-2-branch. I will attempt to
explain the rational of these changes so you understand their importance.
 Previous to gcc 3.1, gcc was exporting certain libgcc symbols, in error,
for linking. Starting with gcc 3.1, these symbols are now .hidden. This means
that if glibc is rebuilt with gcc >= 3.1, old binaries expecting to have
these symbols resolved will fail. In order to address this, ia64 and ppc
have provided libgcc-compat code in glibc to present these symbols for
resolution at run-time but not linking. The current glibc-2-2-branch as
of yesterday is insufficient to properly do this as Ulrich demands that
such symbols not be exported for linking. Unfortunately the current
patch there for this libgcc-compat code exports several of these symbols
for linking. The attached patch stops this behavior limiting all the
libgcc-compat symbols to just run-time resolution.
 In getting to the patch attached below we tickled several
obscure binutils bugs with HJ Lu has been kind enough to fix
and check into binutils cvs...

http://sources.redhat.com/ml/binutils/2002-08/msg00175.html
http://sources.redhat.com/ml/binutils/2002-08/msg00217.html
http://sources.redhat.com/ml/binutils/2002-08/msg00221.html

..these patches are essential! Without them binutils will either
have problems linking other programs (complaining in error about
duplicate symbols with __divdi3) and creating a libgcc_s.so.1
in gcc 3.2 with a properly versioned __divdi3 symbol.
 As soon as Chris has released the next binutils package and either
we use the attached patch or resample upstream from glibc-2-2-branch
for the same patch, we will be set to start building with gcc 3.2 on
ppc. It would be very good idea for us to get this resolved in
2.2.5-14, because current glibc-2-2-branch is exporting versioned
symbols for __divdi3, and few others, with a GLIBC_2.0 versioning.
This didn't happen in glibc prior to glibc 2.2.5-14 and it won't
after we add the patch below (which makes those symbols run-time
resolution only). It would be best if we don't muck around and
build a bunch of stuff on ppc against current glibc-2-2-branch without
the fix so as not to have to worry about those symbols.
 Let me know if you have any specific questions. The process is
really simple..

1) updated binutils from HJ or 2.13.90.0.3 with binutils-version-add and
bfd-version-dso patches from this weekend and today.
2) add in glibc-libgcc-compat-ppc-8-2_2d from below or resample
glibc-2-2-branch once Franz has it in.
3) add a depends to gcc 3.2 for the binutils (>=2.13.90.0.4) and
for glibc (>=2.2.5-14). This step is essential to prevent the
build machines from using gcc-3.2 to build against the wrong,
i.e. old, binutils and/or libc accidentally.

Thanks in advance for helping get this transition to gcc 3.2
correctly done on ppc.