delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin/2005/09/15/09:10:41

Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
MIME-Version: 1.0
Subject: Bug in gcc and/or binutils?
Date: Thu, 15 Sep 2005 15:10:25 +0200
Message-ID: <90459864DAD67D43BDD3D517DEFC2F7D05B22C@axon.Axentia.local>
From: "Peter Ekberg" <peda AT axentia DOT se>
To: <cygwin AT cygwin DOT com>
X-IsSubscribed: yes
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id j8FDAdN8027341

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/


- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019