Geoff,
I just install Xcode 2.4 and compiling the modulo.c testcase still
fails to link...
[Jack-Howarths-Computer:~] howarth% gcc -m64 modulo.c
Undefined symbols:
___modti3, referenced from:
_main in ccXflrzz.o
ld64-59.2 failed: symbol(s) not found
collect2: ld returned 1 exit status
Geoff,
Do you have any idea why linuxppc64 is seeing the missing TImode
symbols and the ppc64 libgcc on Darwin isn't? Do you think
explicitly adding the TImode symbols to the .ver for ppc64 would
resolve the issue? Again I would be happy to test any proposed
patches for resolving the issue that
On 07/08/2006, at 6:11 PM, Jack Howarth wrote:
Geoff,
I am still puzzled by your statement that ".1.dylib files
should never be used
directly in a link". With both gcc trunk and Xcode 2.3, the
following...
[Jack-Howarths-Computer:~] howarth% gcc -O3 -m64 modulo.c -shared-
libgcc
[Ja
Geoff,
I am still puzzled by your statement that ".1.dylib files should never be
used
directly in a link". With both gcc trunk and Xcode 2.3, the following...
[Jack-Howarths-Computer:~] howarth% gcc -O3 -m64 modulo.c -shared-libgcc
[Jack-Howarths-Computer:~] howarth% otool64 -L ./a.out
./a.ou
Geoff,
Looking at this from Xcode 2.3, which doesn't have a dylib for ppc64,
"nm libgcc.a | grep ti" doesn't show anything whereas on x86_64 FC5 Linux
this shows all the TImode symbols. This result isn't surprising since
the gcc 4.0.1 in Xcode 2.3 can't resolve the symbols as well when the
stati
Geoff,
So does that make it a linker bug (ie in odcctools 590-20060608)?
I would note that I see the same problem with the modulo.c and division.c
test cases if I disable fink (remove it from my path) and compile those
sources with the Xcode 2.3 gcc compiler using -m64.
Also I am puzzled by y
On 06/08/2006, at 8:11 PM, David Edelsohn wrote:
I believe that Andrew Pinski diagnosed the problem as divti3 and
modti3 not being listed in the symbol export file for Darwin when
64-bit
support was added.
It is unfortunate that these files cannot have comments, because it
seems
On 06/08/2006, at 9:10 PM, Jack Howarth wrote:
David,
My understanding was that only libgcc_s.10.4.dylib and libgcc_s.
10.5.dylib
required the entries in their .ver files for exporting symbols. The
-m64
flag on Darwin causes libgcc_s_ppc64.1.dylib to be used for the linked
libgcc.
The
> Jack Howarth writes:
Jack> A few questions. Does linuxppc64 use the libgcc-ppc64.ver in
Jack> gcc/config/rs6000 or does it use the stock libgcc-std.ver in the
Jack> gcc directory? I am still unclear which 'owns' libgcc-ppc64.ver
Jack> since it doesn't have darwin explicitly in its name. Also
David,
A few questions. Does linuxppc64 use the libgcc-ppc64.ver in
gcc/config/rs6000 or does it use the stock libgcc-std.ver in the
gcc directory? I am still unclear which 'owns' libgcc-ppc64.ver
since it doesn't have darwin explicitly in its name. Also does
nm -D libgcc_s.so | grep __umodti3
David,
My understanding was that only libgcc_s.10.4.dylib and libgcc_s.10.5.dylib
required the entries in their .ver files for exporting symbols. The -m64
flag on Darwin causes libgcc_s_ppc64.1.dylib to be used for the linked
libgcc. There is a very sparse libgcc-ppc64.ver file in the director
> Jack Howarth writes:
Jack> I've asked David Edelsohn at IBM if he sees the same problem on
Jack> linuxppc64. Unfortunately, I don't have a spare drive handy to
Jack> try it on linuxppc64 myself.
Everything works fine on ppc64 linux.
I believe that Andrew Pinski diagnosed th
Geoff,
I tried the modulo.c and division.c test cases with tonight's
gcc svn pull and the problem shows some variability. Sometimes
building with 'gcc-4 -m64 division.c' or 'gcc-4 -m64 modulo.c'
creates a binary that can resolve the symbol and sometimes not.
So the symbol resolution process see
Geoff,
I've asked David Edelsohn at IBM if he sees the same problem on
linuxppc64. Unfortunately, I don't have a spare drive handy to
try it on linuxppc64 myself.
Jack
On 05/08/2006, at 5:19 PM, Jack Howarth wrote:
While testing the state of gfortran in gcc trunk at -m64 on
MacOS X 10.4
I discovered a huge number of test failures (848 compared to 26
with -m32).
Almost all of these failures appear to be due to two undefined
symbols in
libgfortran's s
The second missing symbol generated by gcc trunk on
MacOS X 10.4 when compiling with -m64 can be demonstrated with
this test case...
main()
{
__int128_t a, b;
b= a / 10;
}
which when compiled with "gcc-4 -m64 division.c" produces the
linkage error...
can't resolve symbols:
___divti3, refer
I can produce the first missing symbol with current gcc trunk on
MacOS X 10.4 using this testcase...
main()
{
__int128_t a, b;
b= a % 10;
}
When compiled with "gcc-4 -m64 modulo.c", this produces the linkage
failure of...
can't resolve symbols:
___modti3, referenced from:
_main in cc8
While testing the state of gfortran in gcc trunk at -m64 on MacOS X 10.4
I discovered a huge number of test failures (848 compared to 26 with -m32).
Almost all of these failures appear to be due to two undefined symbols in
libgfortran's shared library in the ppc64 version...
http://gcc.gnu.org
18 matches
Mail list logo
