This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Bug in gcc and/or binutils?


Hi!

I have been looking at a failure in the testsuite in
libtool-cvs which I have reduced to the following
script. I have included the approximate output from
any program execed by it in comments along with
comments as to what is going wrong.

$ gcc --version | head -1
gcc (GCC) 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
$ ld --version | head -1
GNU ld version 2.16.91 20050610

Etc etc yada yada updated the Cygwin installation the
other day...

This limitation is perhaps already known?

Cheers,
Peter

-----------------------8<-----------------------
#!/bin/bash
run ()
{
	echo $*
	eval $*
}
cat << EOF > a.c
const char* v7 = "foo";
EOF
cat << EOF > main.c
extern const char *v7;
int main(void)
{
  return *v7 - 'f';
}
EOF
cat << EOF > a.def
EXPORTS
v7
EOF
run gcc -c a.c -o a.o
run gcc -c main.c -o main.o
run gcc -shared a.def a.o -o a.dll -Wl,--out-implib,a.bad.lib
#Creating library file: a.bad.lib
run gcc -o bad main.o a.bad.lib
run ./bad
#Segmentation fault (core dumped)
echo returns: $?
#returns: 139
run cp a.dll a.temp.dll

# Experiments reveal that removing a.def from the dll linking
# stage makes it work, like this:

run gcc -shared a.o -o a.dll -Wl,--out-implib,a.good.lib
#Creating library file: a.good.lib
run gcc -o good main.o a.good.lib
#Info: resolving _v7 by linking to __imp__v7 (auto-import)
run ./good
echo returns: $?
#returns: 0

# Further experiments reveal that it is the import lib that is
# the culprit (as the missing Info message in the failing run
# hints at), like this:

run ./bad
#Segmentation fault (core dumped)
echo returns: $?
#returns: 139

# I.e. The exe generated with the bad import lib fails even
# if used with the known working dll.

run cp a.temp.dll a.dll
run ./good
echo returns: $?
#returns: 0

# I.e. The exe generated with the good import lib succeeds even
# if used with the dll from the failing run. So the dll isn't
# bad.

# Ergo, the import lib is bad. Comparing nm output from the two
# import libs reveals a significant difference:

run "nm a.bad.lib > a.bad.nm"
run "nm a.good.lib > a.good.nm"
run diff a.bad.nm a.good.nm
#23c23
#< 00000000 T _v7
#---
#> 00000000 I __nm__v7
-----------------------8<-----------------------

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]