RE: binutils prerelease available for testing (feedback needed)]

RE: binutils prerelease available for testing (feedback needed)]

[Danny Smith]

>From: "Mark E." <snowball3@bigfoot.com>
>To: cygwin@sources.redhat.com
>Subject: RE: binutils prerelease available for testing (feedback needed)]
>Date: Thu, 20 Jul 2000 19:54:57 -0400
>
>Hi guys,
>The patch causing your Binutils problem has been reverted. Sorry about the
>trouble.
>
> > 2000-07-20  DJ Delorie  <dj@redhat.com>
> >
> > 	* config/obj-coff.c (obj_frob_symbol): revert previous change,
> > 	it breaks linking against DLLs.
>
>Could you guys try this one out and verify it causes you guys no problems:
>
This causes no problems in my dll test cases [Mumit's dllhelpers-0.2.5, 
(c,c++, and g77) with and w/o -mnocygwin; odbc++2.2pre3; stlport4.0]

Thanks
Danny
________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: binutils prerelease available for testing (feedback needed)]

[Chris Faylor]

On Fri, Jul 21, 2000 at 02:27:22PM +1200, Danny Smith wrote:
>
>
>>From: "Mark E." <snowball3@bigfoot.com>
>>To: cygwin@sources.redhat.com
>>Subject: RE: binutils prerelease available for testing (feedback needed)]
>>Date: Thu, 20 Jul 2000 19:54:57 -0400
>>
>>Hi guys,
>>The patch causing your Binutils problem has been reverted. Sorry about the
>>trouble.
>>
>> > 2000-07-20  DJ Delorie  <dj@redhat.com>
>> >
>> > 	* config/obj-coff.c (obj_frob_symbol): revert previous change,
>> > 	it breaks linking against DLLs.
>>
>>Could you guys try this one out and verify it causes you guys no problems:
>>
>This causes no problems in my dll test cases [Mumit's dllhelpers-0.2.5, 
>(c,c++, and g77) with and w/o -mnocygwin; odbc++2.2pre3; stlport4.0]
>
>Thanks

Thank you for verifying this.

Do we have any other verification?

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: binutils prerelease available for testing (feedback needed)

[Charles Wilson]

OK!

The problems that I have been seeing must be related to my *overly
complex* testing -- I can only figure there's something in one of my
hacked up libpng .c or .h files that I am overlooking, since I did have
to *hack* libpng so that it would export a data item.

The following tests were done using binutils from CVS 20000721 + Mark
E.'s patch

I downloaded Mumit's dllhelpers, and built the .c version *by hand*
using 'gcc -shared' and this .def file:

EXPORTS
	dll_double_square @ 1 ; 
	dll_float_square @ 2 ; 
	dll_get_global_int_var @ 3 ; 
	dll_global_int_var @ 4 DATA ; 
	dll_int_square @ 5 ; 
	dll_set_global_int_var @ 6 ; 

I even *omitted* the dllinit.o file from the dll, so as to force cygwin
to use the built-in dllinit methods.

Build dll:
gcc -c -DBUILDING_DLL=1 -I. -g -Wall - cdll.o cdll.c
gcc -shared -Wl,--out-implib=libcdll.dll.a -Wl,--enable-auto-image-base
-o libcdll.dll cdll.def cdll.o

Build exec's:
gcc -c -I. -g -Wall -o usedll.o usedll.c

CASE 3 (use import lib)
ld -Bdynamic -o usedll-imp.exe /usr/lib/crt0.o -L./
-L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2
-L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../i686-pc-cygwin/lib
usedll.o -lcdll -lgcc -lcygwin -luser32 -lkernel32 ladvapi32 -lshell32
-lgcc

CASE 2 (link direct to dll) 
mv libcdll.dll.a libcdll.dll.a.foo
ld -Bdynamic -o usedll-dll.exe /usr/lib/crt0.o -L./
-L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2
-L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.2/../../../../i686-pc-cygwin/lib
usedll.o -lcdll -lgcc -lcygwin -luser32 -lkernel32 ladvapi32 -lshell32
-lgcc


Both usedll-imp.exe and usedll-dll.exe worked fine. Taking a look at the
executable symbols:

nm -a usedll-imp.exe | grep dll_global_int_var
008040b4 I __imp__dll_global_int_var

nm -a usedll-dll.exe | grep dll_global_int_var
008040e8 I __imp__dll_global_int_var
00801590 T _dll_global_int_var

Interesting: when using the import lib, you only get the __imp__ symbol,
but when linking directly to the dll (i.e. using a virtual import lib)
you get both symbols. In either case, however, the executable works
properly.

My earlier reported problems must have been due to mistakes in my hacked
up libpng, but I haven't located them. Sorry for the confusion.

--Chuck




(used the same link command to

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: binutils prerelease available for testing (feedback needed)

[Charles Wilson]

Danny Smith wrote:
> 
> >From: Charles Wilson <cwilson@ece.gatech.edu>
> >To: Danny Smith <danny_r_smith@hotmail.com>, cygwin@sources.redhat.com
> >Subject: Re: binutils prerelease available for testing (feedback needed)
> >Date: Fri, 21 Jul 2000 00:57:46 -0400
> >
> >Okay, it's confirmed -- I've just built cvs 20000721 + Mark E's patch.
> >Same behavior as before, no worse (no better).
> >
> >--Chuck
> > > CASE 3: 'USE_GLOBAL_ARRAYS' #define'd (dll exports png_libpng_ver as a
> > > DATA item)
> > > I can link using the import lib. Executable stackdumps.
> > >
> > > Danny, when you ran your tests, did your DLL export any DATA items?
> > >
> Yes, all my test cases (except Fortran) exported DATA.  The C++ code
> exported classes and instances of these class. Some of the classes had
> static data members that were exported. Dlls were built using
> __declspec(dllexport) in code.    All imports were marked in client code
> using __declspec(dllimport) attribute.
> 

!!!!! these are the correct rules. I was following them as well. I'm
flabbergasted.

Danny -- can you do me a favor? Build three versions of an executable,
linking to the static lib, directly to the dll (verify using 'ld
--verbose' that your build is NOT finding the dll or static lib or
hunting in some unexpected directory), and using the import library.

Then, pick a 'DATA' symbol in the dll, and do:

nm prog_stat.exe | grep 'my_symbol'
nm prog_dll.exe | grep 'my_symbol'
nm prog_imp.exe | grep 'my_symbol'

I believe my problem is that my 'prog_imp.exe' contains only a 'I
__imp__my_symbol' and no 'T _my_symbol', whereas my prog_dll.exe
contains both. I'd like to know what your prog_imp.exe contains...

Thanks,
Chuck

Note: to get the 'correct' ld command line, I've used 'gcc --verbose' as
my initial link command, then used the collect2.exe line that gcc
reported as my 'real' link command.

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: binutils prerelease available for testing (feedback needed)]

[Fifer, Eric]

Mark E. wrote:
>The patch causing your Binutils problem has been reverted. Sorry about the 
>trouble.
>
>> 2000-07-20  DJ Delorie  <dj@redhat.com>
>> 
>> 	* config/obj-coff.c (obj_frob_symbol): revert previous change,
>> 	it breaks linking against DLLs.
>
>Could you guys try this one out and verify it causes you guys no problems:
> [...]

I tried out your patch, and everything is still okay.

Thanks,

Eric Fifer


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: binutils prerelease available for testing (feedback needed)

[Danny Smith]

>From: Charles Wilson <cwilson@ece.gatech.edu>
>To: Danny Smith <danny_r_smith@hotmail.com>, cygwin@sources.redhat.com
>Subject: Re: binutils prerelease available for testing (feedback needed)
>Date: Fri, 21 Jul 2000 00:57:46 -0400
>
>Okay, it's confirmed -- I've just built cvs 20000721 + Mark E's patch.
>Same behavior as before, no worse (no better).
>
>--Chuck
> > CASE 3: 'USE_GLOBAL_ARRAYS' #define'd (dll exports png_libpng_ver as a
> > DATA item)
> > I can link using the import lib. Executable stackdumps.
> >
> > Danny, when you ran your tests, did your DLL export any DATA items?
> >
Yes, all my test cases (except Fortran) exported DATA.  The C++ code 
exported classes and instances of these class. Some of the classes had 
static data members that were exported. Dlls were built using 
__declspec(dllexport) in code.    All imports were marked in client code 
using __declspec(dllimport) attribute.



Regards Danny


________________________________________________________________________
Get Your Private, Free E-mail from MSN Hotmail at http://www.hotmail.com


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: binutils prerelease available for testing (feedback needed)

[Charles Wilson]

Okay, it's confirmed -- I've just built cvs 20000721 + Mark E's patch.
Same behavior as before, no worse (no better).

--Chuck

P.S. 

CASE 1:  static link, 'USE_GLOBAL_ARRAYS'
nm pngtest-stat.exe | grep png_libpng_ver

0082f044 D _png_libpng_ver

executable works fine.

CASE 2:  dynamic link (direct to dll, using virtual import lib)
'USE_GLOBAL_ARRAYS'
nm pngtest.exe | grep png_libpng_ver

0080627c I __imp__png_libpng_ver
00803630 T _png_libpng_ver

executable works fine.

CASE 3:  dynamic link (using .dll.a import lib) 'USE_GLOBAL_ARRAYS'
nm pngtest.exe | grep png_libpng_ver

0080620c I __imp__png_libpng_ver
<<<< NO  T _png_libpng_ver >>>>>

executable stackdumps.

CASE 4 - 6 omitted.




Charles Wilson wrote:
> 
> I've tried building binutils in three ways:
> 
>   cvs 20000718
>   cvs 20000718 with the gas/config/obj-coff.c patch reverted
>   cvs 20000721 (after DJ reverted the gas/config.obj-coff.c patch in
> CVS)
> 
> I will try using the patch posted to the cygwin list by Mark E. on
> 2000-7-20 at 19:54 EDT.
> 
> In all three tested cases, I get the same behavior with libpng, pngtest,
> *with png_libpng_ver exported as DATA*.
> 
> --------------------------------
> 
> CASE 1: 'USE_GLOBAL_ARRAYS' #define'd -- this forces access to
> 'png_libpng_ver' to directly refer to a character array, rather than
> being #defined into an access_function: 'png_get_header_ver()'
> 
> I can link statically. Executable works fine.
> 
> CASE 2: 'USE_GLOBAL_ARRAYS' #define'd (dll exports png_libpng_ver as a
> DATA item)
> I can link directly to the dll (that is, remove the import lib and the
> static lib from the search path, *forcing* ld to link with the dll using
> a virtual, in-memory, generate-on-the-fly import lib. Executable works
> fine.
> 
> CASE 3: 'USE_GLOBAL_ARRAYS' #define'd (dll exports png_libpng_ver as a
> DATA item)
> I can link using the import lib. Executable stackdumps.
> 
> CASE 4: 'NO_GLOBAL_ARRAYS' #define'd (causes: #define png_libpng_ver
> png_get_header_ver(); png_libpng_ver DOES NOT APPEAR anywhere in the
> dll, importlib, static lib, or executable.
> 
> I can link statically. Executable works fine.
> 
> CASE 5: 'NO_GLOBAL_ARRAYS' #define'd. dll contains NO DATA items.
> I can link directly to the dll. Executable works fine.
> 
> CASE 6: 'NO_GLOBAL_ARRAYS' #define'd.
> I can link using the import lib libpng.dll.a. Executable works fine.
> 
> ----------------------------------
> 
> Danny, when you ran your tests, did your DLL export any DATA items?
> 
> The problem seems to be that the combination of: 'link using an import
> lib' + 'DATA items exported by dll' doesn't work. None of the proposed
> fixes helps this problem. (Haven't tested Mark E.'s patch yet)
> 
> --Chuck
> 
> Charles Wilson wrote:
> >
> > I'll check to see if this eliminates my problems, later tonight.
> >
> > --Chuck
> >
> > Danny Smith wrote:
> > >
> > > Hi
> > > You may be ahead of me on this but...
> > > I have experienced similar problems as report by Eric Fifer and Charles
> > > Wilson using binutils-000718, with access violations linking against C
> > > dlls with data exports or with C++ dlls.
> > >
> > > But, rebuilding binutils-000718 after reverting the changes made to
> > > gas/config/obj_coff.c
> > > ( http://sources.redhat.com/ml/binutils/2000-07/msg00226.html )  back to
> > > binutils-000717 version, I can successfully build and link against dlls,
> > > using either dllwrap or gcc -shared.  This works also with -mno-cygwin.
> > > I have tested linking against implib as well as directly aginst dll
> > > without implib.  Both work, for C and C++, and dll data is exported
> > > correctly.   Also with standalone MingW.
> > >
> > > Hope this helps.
> > >
> > > Regards
> > >
> > > --
> > > Want to unsubscribe from this list?
> > > Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> >
> > --
> > Want to unsubscribe from this list?
> > Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: binutils prerelease available for testing (feedback needed)

[Charles Wilson]

I've tried building binutils in three ways:

  cvs 20000718
  cvs 20000718 with the gas/config/obj-coff.c patch reverted
  cvs 20000721 (after DJ reverted the gas/config.obj-coff.c patch in
CVS)

I will try using the patch posted to the cygwin list by Mark E. on
2000-7-20 at 19:54 EDT.

In all three tested cases, I get the same behavior with libpng, pngtest,
*with png_libpng_ver exported as DATA*.

--------------------------------

CASE 1: 'USE_GLOBAL_ARRAYS' #define'd -- this forces access to
'png_libpng_ver' to directly refer to a character array, rather than
being #defined into an access_function: 'png_get_header_ver()'

I can link statically. Executable works fine.

CASE 2: 'USE_GLOBAL_ARRAYS' #define'd (dll exports png_libpng_ver as a
DATA item)
I can link directly to the dll (that is, remove the import lib and the
static lib from the search path, *forcing* ld to link with the dll using
a virtual, in-memory, generate-on-the-fly import lib. Executable works
fine.

CASE 3: 'USE_GLOBAL_ARRAYS' #define'd (dll exports png_libpng_ver as a
DATA item)
I can link using the import lib. Executable stackdumps.

CASE 4: 'NO_GLOBAL_ARRAYS' #define'd (causes: #define png_libpng_ver
png_get_header_ver(); png_libpng_ver DOES NOT APPEAR anywhere in the
dll, importlib, static lib, or executable.

I can link statically. Executable works fine.

CASE 5: 'NO_GLOBAL_ARRAYS' #define'd. dll contains NO DATA items.
I can link directly to the dll. Executable works fine.

CASE 6: 'NO_GLOBAL_ARRAYS' #define'd. 
I can link using the import lib libpng.dll.a. Executable works fine.

----------------------------------

Danny, when you ran your tests, did your DLL export any DATA items? 

The problem seems to be that the combination of: 'link using an import
lib' + 'DATA items exported by dll' doesn't work. None of the proposed
fixes helps this problem. (Haven't tested Mark E.'s patch yet)

--Chuck


Charles Wilson wrote:
> 
> I'll check to see if this eliminates my problems, later tonight.
> 
> --Chuck
> 
> Danny Smith wrote:
> >
> > Hi
> > You may be ahead of me on this but...
> > I have experienced similar problems as report by Eric Fifer and Charles
> > Wilson using binutils-000718, with access violations linking against C
> > dlls with data exports or with C++ dlls.
> >
> > But, rebuilding binutils-000718 after reverting the changes made to
> > gas/config/obj_coff.c
> > ( http://sources.redhat.com/ml/binutils/2000-07/msg00226.html )  back to
> > binutils-000717 version, I can successfully build and link against dlls,
> > using either dllwrap or gcc -shared.  This works also with -mno-cygwin.
> > I have tested linking against implib as well as directly aginst dll
> > without implib.  Both work, for C and C++, and dll data is exported
> > correctly.   Also with standalone MingW.
> >
> > Hope this helps.
> >
> > Regards
> >
> > --
> > Want to unsubscribe from this list?
> > Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: binutils prerelease available for testing (feedback needed)]

[Mark E.]

Hi guys,
The patch causing your Binutils problem has been reverted. Sorry about the 
trouble.

> 2000-07-20  DJ Delorie  <dj@redhat.com>
> 
> 	* config/obj-coff.c (obj_frob_symbol): revert previous change,
> 	it breaks linking against DLLs.

Could you guys try this one out and verify it causes you guys no problems:

Index: src/gas/config/obj-coff.c
===================================================================
RCS file: /cvs/src/src/gas/config/obj-coff.c,v
retrieving revision 1.31
diff -c -p -r1.31 obj-coff.c
*** obj-coff.c	2000/07/20 23:38:05	1.31
--- obj-coff.c	2000/07/20 23:48:04
*************** coff_frob_symbol (symp, punt)
*** 1139,1149 ****
--- 1139,1152 ----
        symbolS *real;
        if (!SF_GET_LOCAL (symp)
  	  && !SF_GET_STATICS (symp)
+ 	  && S_GET_STORAGE_CLASS (symp) != C_LABEL
+ 	  && symbol_constant_p(symp)
  	  && (real = symbol_find_base (S_GET_NAME (symp), DO_NOT_STRIP))
  	  && real != symp)
  	{
  	  c_symbol_merge (symp, real);
  	  *punt = 1;
+ 	  return;
  	}
        if (!S_IS_DEFINED (symp) && !SF_GET_LOCAL (symp))
  	{


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: binutils prerelease available for testing (feedback needed)

[Fifer, Eric]

Danny Smith wrote:
>But, rebuilding binutils-000718 after reverting the changes made to
>gas/config/obj_coff.c
>( http://sources.redhat.com/ml/binutils/2000-07/msg00226.html )  back to
>binutils-000717 version, I can successfully build and link against dlls,
>using either dllwrap or gcc -shared.

Yes, rebuilding binutils-20000718-1 with the patch you mention
reversed out, clears up the problems I'm seeing.

Thanks,

Eric Fifer

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: binutils prerelease available for testing (feedback needed)

[Charles Wilson]

I'll check to see if this eliminates my problems, later tonight.

--Chuck


Danny Smith wrote:
> 
> Hi
> You may be ahead of me on this but...
> I have experienced similar problems as report by Eric Fifer and Charles
> Wilson using binutils-000718, with access violations linking against C
> dlls with data exports or with C++ dlls.
> 
> But, rebuilding binutils-000718 after reverting the changes made to
> gas/config/obj_coff.c
> ( http://sources.redhat.com/ml/binutils/2000-07/msg00226.html )  back to
> binutils-000717 version, I can successfully build and link against dlls,
> using either dllwrap or gcc -shared.  This works also with -mno-cygwin.
> I have tested linking against implib as well as directly aginst dll
> without implib.  Both work, for C and C++, and dll data is exported
> correctly.   Also with standalone MingW.
> 
> Hope this helps.
> 
> Regards
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: binutils prerelease available for testing (feedback needed)

[Danny Smith]

Hi
You may be ahead of me on this but...
I have experienced similar problems as report by Eric Fifer and Charles
Wilson using binutils-000718, with access violations linking against C
dlls with data exports or with C++ dlls.

But, rebuilding binutils-000718 after reverting the changes made to
gas/config/obj_coff.c
( http://sources.redhat.com/ml/binutils/2000-07/msg00226.html )  back to
binutils-000717 version, I can successfully build and link against dlls,
using either dllwrap or gcc -shared.  This works also with -mno-cygwin.
I have tested linking against implib as well as directly aginst dll
without implib.  Both work, for C and C++, and dll data is exported
correctly.   Also with standalone MingW.

Hope this helps.

Regards


--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: binutils prerelease available for testing (feedback needed)

[Chris Faylor]

On Wed, Jul 19, 2000 at 04:33:14PM +0100, Fifer, Eric wrote:
>
>Chris Faylor wrote:
>>I have done zero testing with this so I would really appreciate
>>feedback on whether this solves the various dllwrap and ld problems
>>that people have noticed.
>
>The new dllwrap works.
>
>However, now I'm having some mysterious problem with a Perl
>module (Win32::OLE) which is C++ and uses -fvtable-thunks.
>It definitely works with binutils-20000625, so I'll try to
>isolate the problem ...

Sounds like we have the typical moving target.

Thanks for trying this.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

RE: binutils prerelease available for testing (feedback needed)

[Fifer, Eric]

Chris Faylor wrote:
>I have done zero testing with this so I would really appreciate
>feedback on whether this solves the various dllwrap and ld problems
>that people have noticed.

The new dllwrap works.

However, now I'm having some mysterious problem with a Perl
module (Win32::OLE) which is C++ and uses -fvtable-thunks.
It definitely works with binutils-20000625, so I'll try to
isolate the problem ...

Regards,

Eric Fifer

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: binutils prerelease available for testing (feedback needed)

[Charles Wilson]

Chris --
  I haven't tested *your* version, 'cause I was in the process of
building binutils from CVS at the same time. So, mine *should* be the
same as yours -- and I get a strange failure. I'll verify with your
version soon:

building libpng, BUT after I explicitly set some #defines so that the
library exported 'png_libpng_ver' as a DATA item, instead of the normal
behavior where it gets #defined into a macro that calls
'png_get_header_ver()'. I built both a dll+import lib, and a static lib.

CASE 1:
Then, I built pngtest-stat.exe (which linked to libpng.a, the static
lib). Worked fine. Accesses the static array 'png_libpng_ver':

nm pngtest-stat.exe | grep png_libpng_ver
0082f044 D _png_libpng_ver

CASE 2:
Next, I built pngtest.exe, (linked to libpng.dll.a, the import lib).
Stackdump

      0 [main] pngtest 6828 handle_exceptions: Exception:
STATUS_ACCESS_VIOLATION
   5393 [main] pngtest 6828 stackdump: Dumping stack trace to
pngtest.exe.stackdump

nm pngtest.exe | grep png_libpng_ver
0080620c I __imp__png_libpng_ver

CASE 3:
Finally, I rebuilt pngtest.exe, but after renaming libpng.dll.a and
libpng.a so that they wouldn't be used in the link process -- that is, I
forced ld to link directly to the dll. It worked.

nm pngtest.exe | grep png_libpng_ver
0080627c I __imp__png_libpng_ver
00803630 T _png_libpng_ver

It seems that somehow, somewhere, import libraries with DATA items
became broken. (Counterintuitively, though, you can successfully link
directly to the dll containing DATA items -- so the 'virtual' import lib
used in that case is correct!) I tried to debug CASE 2 using gdb, but
when I loaded that pngtest.exe, *gdb* stackdumped.

Behavior is as expected in all cases when the dll does not contain DATA
items. None of the executables contained a 'png_libpng_ver' symbol; they
only contained the png_get_header_ver() symbol. All linked and ran okay.

--Chuck

Chris Faylor wrote:
> 
> On Tue, Jul 18, 2000 at 08:01:09PM -0400, DJ Delorie wrote:
> >> Thanks.  Your patch for ld, fixed the ld -r problem.  Thanks a lot.
> >
> >Great!
> >
> >> Do you plan to update the binutils distribution archive?
> >
> >Chris has been doing that, so I don't know.
> 
> Funny you should ask.  I just built a version of binutils that may
> well be the next version.
> 
> If you want to try out an untested prerelease version, it's at:
> 
> ftp://ftp.cygnus.com/private/cgf/binutils-20000718-1.tar.gz
> ftp://ftp.cygnus.com/private/cgf/binutils-20000718-1-src.tar.gz
> 
> I have done zero testing with this so I would really appreciate
> feedback on whether this solves the various dllwrap and ld problems
> that people have noticed.
> 
> cgf
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

binutils prerelease available for testing (feedback needed)

[Chris Faylor]

On Tue, Jul 18, 2000 at 08:01:09PM -0400, DJ Delorie wrote:
>> Thanks.  Your patch for ld, fixed the ld -r problem.  Thanks a lot.
>
>Great!
>
>> Do you plan to update the binutils distribution archive?
>
>Chris has been doing that, so I don't know.

Funny you should ask.  I just built a version of binutils that may
well be the next version.

If you want to try out an untested prerelease version, it's at:

ftp://ftp.cygnus.com/private/cgf/binutils-20000718-1.tar.gz
ftp://ftp.cygnus.com/private/cgf/binutils-20000718-1-src.tar.gz

I have done zero testing with this so I would really appreciate
feedback on whether this solves the various dllwrap and ld problems
that people have noticed.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com