On 2008-09-08 06:44+0200 Arjen Markus wrote: >> Hi, >> >> the email below was somehow never sent, since it stayed in my Drafts >> folder, so I send it again. >> >> Werner >> >> Ok, >> >> one step forward. The import library libplplotf77cd.dll.a (to which is >> linked to) doesn't contain any symbols. If I change in plstubs.h >> STUB_LAU to >> >> #define FNAME(x,y) PLDLLIMPEXP y##_ >> #define FNAME_(x,y) y##_ >> >> it's still not possible to link to libplplotf77cd.dll.a (although it >> contains symbols of the correct name - but it's possible to link >> directly to libplplotf77cd.dll if I make changes to the files produced >> by cmake. So it seems that for MinGW 4.x.x the functions are also not >> exported by default (as with Visual C++) - I thought that this is now >> possible but not default (there is some visibility flag which can be set). >> >> Maybe someone has some additional ideas. >> > > Hi Werner, > > once I got it all working, I noticed the same thing: for some > reason the import library (.dll.a) contains very few symbols. > I have experimented a bit with STUB_LAU, but that has not solved > much. > > The way forward is to write a small set of source files that > mimick the set-up of PLplot - by then compiling/linking them > manually I should be able to determine the correct incantation. > > But I come to the same conclusion: this version of GCC hides > the symbols just like other Windows compilers. I am not sure > I like that particular complication ;).
Also, please note that I have been working on gcc visibility issues recently so I may have inadvertently messed up the MinGW version of GCC case. The the PLplot trunk version right now, all is well for Linux gcc because I use the "(default)" case (i.e., everything visible) in plplot.h, but it is possible that logic is failing somehow for the MinGW/gcc case so you are not getting the "all symbols visible" result like you are supposed to with that "(default)" setting. As a nasty side note, when Andrew or I try "(hidden)" completely inexplicable results occur for the visibility of symbols in our core library with Linux/gcc. The majority of c_* symbols are visible, but some are not for unknown reasons which messes up everything else, and the list of those symbols which are invisible varies from my Debian Linux platform to Andrew's closely related Ubuntu Linux platform. (Huh??) In sum, something really strange seems to be going on with gcc visibility on Linux for the "(hidden)" case with PLDLLIMPEXP being ignored for some of our symbols but not others in a platform-dependent way. Something different but also strange may be going on with MinGW/gcc visibility even for the svn trunk "(default)" case. Thus, Werner and Arjen, as you debug visibility for the MinGW/gcc case, please keep us closely informed since there may be implications for Linux/gcc visibility. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
