Hi Charles,
(*) tentative because I can't actually test it myself against HEAD,
given the pre-existing problem with binutils HEAD on pe386.
The unwanted symbols, which this patch avoid, seems to be exported in some
packages. When this patch is applied, perhaps it makes sense to update the
In theory, it looks good. However, have you tested the following:
a) build a dll using an unmodified ld.
b) build an app that uses that dll, and which accesses both a function
export and a data export from the dll.
c) rebuild the dll using your modified ld.
d) does the app still work,
In theory, it looks good. However, have you tested the following:
a) build a dll using an unmodified ld.
ls /usr/i686-pc-cygwin/bin/ -l
lrwxrwxrwx1 1002 Kein 26 Apr 19 07:49 ar.exe -
/usr/bin/ar.exe
lrwxrwxrwx1 1002 Kein 26 Apr 19 07:49 as.exe -
Ralf Habacker wrote:
b) build an app that uses that dll, and which accesses both a function
export and a data export from the dll.
$ cat client.cc
#include stdio.h
#include dll.h
main()
Ralf Habacker
-Original Message-
From: Charles Wilson [mailto:[EMAIL PROTECTED]]
Sent: Saturday, April 27, 2002 6:55 PM
To: Ralf Habacker
Cc: Kde-Cygwin; Cygwin-Apps; Binutils
Subject: Re: cygwin ld import library issue fix (removing unused _nm_
symbols)
Ralf Habacker
--- Ralf Habacker [EMAIL PROTECTED] wrote: (*) tentative because
I can't actually test it myself against HEAD,
given the pre-existing problem with binutils HEAD on pe386.
I have tried,it works, Danny Smith seems to have fixed the bugs located in
bfd.
Alan Modra fixed it, not me.
Hi,
this patch fixes an cygwin ld issue (GNU ld version 2.11.92 20011001) I've
encountered while analysing the runtime linking performance for kde.
Background:
The ld-auto-import stuff introduces additional symbols (_nm_...) in the import
library which are only needed for data exports.
--- Ralf Habacker [EMAIL PROTECTED] wrote: Hi,
this patch fixes an cygwin ld issue (GNU ld version 2.11.92 20011001) I've
encountered while analysing the runtime linking performance for kde.
Background:
The ld-auto-import stuff introduces additional symbols (_nm_...) in the
import
Hi Danny,
Yes, this looks very nice, but does it works against current CVS?
This patch is a minor change, which could be reviewed easy, but I have got
trouble using the current cvs head (binutils 2-12.xx) release from
sources.redhat.com.
It produces undefined symbols compiling dll/apps and
On Thu, Apr 25, 2002 at 01:32:47PM +0200, Ralf Habacker wrote:
Hi Danny,
Yes, this looks very nice, but does it works against current CVS?
This patch is a minor change, which could be reviewed easy, but I have got
trouble using the current cvs head (binutils 2-12.xx) release from
+ // RH: prevent generating reimported functions
Do not use C++ style comments in C code. It is non-portable.
+ // RH: prevent generating reimported functions
Do not use C++ style comments in C code. It is non-portable.
Don't you mean C99 style comments?
Would be portable if the world adopted a standard now 2 years old...
Don't you mean C99 style comments?
If I had meant C99, I would have said C99.
Would be portable if the world adopted a standard now 2 years old...
You may dream all you like, but portable means works on all the
systems we support. We cannot control the systems. We can control
our sources.
Do not use C++ style comments in C code. It is non-portable.
This is an updated patch against the current cvs release and without c++
comments and a (I hope) propper changeLog entry.
2002-04-25 Ralf Habacker [EMAIL PROTECTED]
* pe-dll.cc (autofilter_symbolprefixlist): don't
In theory, it looks good. However, have you tested the following:
a) build a dll using an unmodified ld.
b) build an app that uses that dll, and which accesses both a function
export and a data export from the dll.
c) rebuild the dll using your modified ld.
d) does the app still work, without
On Thu, Apr 25, 2002 at 01:32:47PM +0200, Ralf Habacker wrote:
Hi Danny,
Yes, this looks very nice, but does it works against current CVS?
This patch is a minor change, which could be reviewed easy, but I have got
trouble using the current cvs head (binutils 2-12.xx) release from
--- Ralf Habacker [EMAIL PROTECTED] wrote:
Can anybody tell me which cvs version is the last stable ? I have tried to
checkout binutils with date 2001/12/31, but got compiling errors.
Compiling errors are fixed (was an overseen cvs conflict, but the problem
still
remains).
So it
* emultempl/pe.em (gld_${EMULATION_NAME}_place_orphan): Likewise.
Then this file could only be affected
When you take a look at the following changelog entry I assume, that this isn't
the problem, because there are only 4 changed lines, much more changes
ld was broken between 16 Dec (works) and 17 Dec (doesn't). The breakage was
reported to binutils list in January. I think, the problem is with merging of
sections in pe-dll.c in make_head() when making implib.
Another question: Does bfd have a debug mode or something else ?
Ralf
--- Ralf Habacker [EMAIL PROTECTED] wrote:
Can anybody tell me which cvs version is the last stable ? I
have tried to
checkout binutils with date 2001/12/31, but got compiling errors.
Compiling errors are fixed (was an overseen cvs conflict, but the problem
still
remains).
You may dream all you like, but portable means works on all the
systems we support. We cannot control the systems. We can control
our sources. Portability precludes //-style comments in binutils.
Well - personally I thought you had gcc to support all your platforms, which
for ages has
Well - personally I thought you had gcc to support all your
platforms, which for ages has supported either style of
comment... there's only a few relics I've run across which were
barely even functional as compilers that didn't support it :)
gcc and binutils are the two packages that are at
22 matches
Mail list logo
