Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner AT sources DOT redhat DOT com Delivered-To: mailing list cygwin AT sources DOT redhat DOT com Message-ID: <3A7E3CF4.39BEB71F@ece.gatech.edu> Date: Mon, 05 Feb 2001 00:41:08 -0500 From: Charles Wilson X-Mailer: Mozilla 4.75 [en] (Windows NT 5.0; U) X-Accept-Language: en MIME-Version: 1.0 To: Jerome BENOIT , cygwin AT sources DOT redhat DOT com Subject: Re: [ANNOUNCEMENT] Updated: libpng-1.0.9-3 References: <200102042131 DOT f14LVNr13796 AT rtl DOT cygnus DOT com> <3A7DFCAC DOT 6F846E99 AT Wanadoo DOT fr> <3A7E1D98 DOT 59466F66 AT ece DOT gatech DOT edu> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Charles Wilson wrote: > > Jerome BENOIT wrote: > > > > Bonjour: > > > > When I launch one of my EXE build with the previous version I get > > an "Error Starting Program" window with the message: > > > > The X.EXE file is linkeked to missing export CYGPNG2.DLL:png_init_io > > > > I hope it helps, > > Jerome BENOIT Well, I'm afraid I can't help you. It turns out that this is a "fix". Here's what happened: In 1.0.8, "png_init_io" was not listed in the .def file that determines what functions/variables are or are not exported from the dll. The last defined export was at ordinal #168 = png_access_version_number. Note that cygwin uses the msvc .def file -- rather than maintain a completely separate but almost identical one. Cygwin just munges the format a little bit during the build process. However, if a function in the source code is declared __declspec(dllexport), then gcc will automatically add it to the export table -- even if it is not in the .def file. Well, png_init_io was one of those functions -- the developers marked it __declspec(dllexport) but forgot (in 1.0.8) to add it to the .def file. So, in 1.0.8, you had an "unofficial" exported function; as it happens, it was automagically assigned ordinal #170. However, in 1.0.9 they fixed the oversight, and explicitly assigned to it the ordinal number #171. Now, if your application linked to dll exports via the name table, there would be no problem; but apparently your app was "link by ordinal" (I'm not sure how to force ld to do one or the other). Thus, your app went looking for png_init_io at #170, but found nothing there (here's where it gets confusing): At one point during the release candidate cycle for 1.0.9, the following exports were added to the .def file after png_access_version_number: png_sig_bytes @169 png_libpng_ver @170 png_init_io @171 png_convert_to_rfc1123 @172 png_set_invalid @173 png_permit_mng_features @174 png_mmx_support @175 However, for various reasons it was decided that some of these should be removed until the 1.2.0 series -- so the final tail of the .def file looks like: ; png_sig_bytes @169 ; png_libpng_ver @170 png_init_io @171 png_convert_to_rfc1123 @172 png_set_invalid @173 ;To be added at version 1.2.0 ; png_permit_mng_features @174 ;To be added at version 1.2.0 ; png_mmx_support @175 Notice that there is NO export at #170. *THAT'S* why your program is breaking. Unfortunately, this is a png-developer level thing, and not a cygwin-specific thing that *I* am able to change. The only recourse, I'm afraid, is one the following: (1) stick with 1.0.8-2 (2) recompile your app with 1.0.9-3. One reason they did not notice a problem is this: on pure windows builds, PNG_NO_STDIO is defined -- which causes png_init_io to be #ifdef'ed out completely. Only on cygwin do you get (a) a dll, plus (b) !PNG_NO_STDIO. sorry for the difficulty, but the above choices are the best I can give you. --Chuck -- Want to unsubscribe from this list? Check out: http://cygwin.com/ml/#unsubscribe-simple