Re: ld -r Unsupported PEI arch pe-i386

Re: ld -r Unsupported PEI arch pe-i386

[Suhaib Siddiqi]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 503 bytes --]

DJ, 

Thanks.  Your patch for ld, fixed the ld -r problem.
Thanks a lot.  Do you plan to update the binutils
distribution archive, one other person reported same
problem, whose e-mail I forwarded to list yesterday.

Thanks a lot for your help.

Suhaib

__________________________________________________
Do You Yahoo!?
Get Yahoo! Mail – Free email you can access from anywhere!
http://mail.yahoo.com/

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

Re: ld -r Unsupported PEI arch pe-i386

[DJ Delorie]

> 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.

--
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

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 mark 2 available for testing (feedback needed)

[Chris Faylor]

I've uploaded what I hope will be the next version of binutils here:

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

Please give this a try and let the cygwin list know if there are problems.

This version has all of the patches that I've seen float by to correct
the problem with the previous prerelease.

cgf

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

Re: binutils prerelease mark 2 available for testing (feedback needed)

[Charles Wilson]

Chris Faylor wrote:
> 
> I've uploaded what I hope will be the next version of binutils here:
> 
> ftp://ftp.cygnus.com/private/cgf/binutils-20000722-1.tar.gz
> ftp://ftp.cygnus.com/private/cgf/binutils-20000722-1-src.tar.gz
> 
> Please give this a try and let the cygwin list know if there are problems.
> 
> This version has all of the patches that I've seen float by to correct
> the problem with the previous prerelease.

Well, it seems to basically work -- I've rebuilt all five libraries that
I've posted recently, and they all seem to work and pass their internal
tests.

However, I can unfortunately confirm Danny Smith's complaint, at least
in part:

> ld -shared (prerelease binutils-20000722-1) appears to ignore the
> ordinal values supplied in a .def when building dlls.

With zlib, the dll export ordinals are the same as that specified by the
.def file -- but, the def file (a) contains every function in the dll --
basically, an 'export-all' def-file, and (b) the functions themselves
are arranged in alphabetical order in the def file. I'm not sure if (a)
and/or (b) are relevant.

------

With libpng, the def file does not contain all the functions, and is not
in alphabetical order (although it's *close* to alphabetical). For some
reason, the dll exports additional functions not listed in the def file,
and the 'extra' exported functions are interspersed within the
'official' exports, bumping the ordinal numbers within the dll around.
The command used to build the dll:

gcc -shared -Wl,--enable-auto-image-base -o libpng.dll
-Wl,--out-implib=libpng.dll.a libpng.def png.pic.o pngset.pic.o
pngget.pic.o pngrutil.pic.o pngtrans.pic.o pngwutil.pic.o pngread.pic.o
pngrio.pic.o pngwio.pic.o pngwrite.pic.o pngrtran.pic.o pngwtran.pic.o
pngmem.pic.o pngerror.pic.o pngpread.pic.o  -L. -L/usr/lib -lz 

------

jbig -- same as zlib, originally. That is, alphabetical .def file, and
the def file exported everything. dependwalk showed that dll ordinals ==
def ordinals.

Then I got creative. I scrambled the .def file (but didn't leave out any
of the exports.) In that case, dependwalk showed that the dll ordinals
in the new dll == the new def ordinals.

So, it seems that the problem is these wacky 'extra' exports. 

New test: go back to the original, alphabetical .def file, and delete
three or four of the exports -- see what happens:

ARRGGHH. The ordinals in the new dll == the new def ordinals. No extra
exports. The functions that were removed from the def file are not
exported by the dll, even though they are marked with
__declspec(dllexport) in the code.

Okay, go back to libpng. What's wacky about it?

-------

AHA! Okay, one of the 'extra' exports is png_convert_to_rfc1123. That
symbol does NOT appear in the .def file. BUT, it is marked as
__declspec(dllexport) in the source code.  So, let's add all three of
the 'extra' symbols to the .def file.

  png_convert_to_rfc1123       @169
  png_init_io  @170
  png_set_invalid      @171

and rebuild the dll.

Double AARRGGHH. No change. The ordinals in the dll are scrambled w.r.t
the order specified by the .def file. Neither the dll ordinals nor the
.def ordinals are alphabetized.

I'm stumped. Sometimes ld -shared pays attention to the ordinals in the
def file (see jbig) and sometimes it does not.

Can someone enlighten me?

--Chuck

--
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)

[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)

[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)

[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)

[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)

[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)

[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)]

[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)]

[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)

[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]

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)

[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)]

[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