Re: [Plplot-devel] fortran iargc() and getarg() on Cygwin

[Arjen M. <arj...@wl...>]

"Alan W. Irwin" wrote:
> 

> 
> Thanks for your experiments so far.
> 
> However, I am not sure your above compile step is actually going to create a
> shared library for Cygwin.  From your previous shared library compile runs
> for the PLplot build, here is the equivalent of how libtool would do it on
> Cygwin (assuming you ignore -fPIC which I agree with you seems irrelevant
> from the above messages).
> 
> #Create compiled object.  This step appears to be the same as required for
> #the static case on Cygwin.
> g77 chkargs.f -o chkargs.o
> #Create shared library from that compiled object
> g77 -shared chkargs.o -o cygplplotf77d-9.dll \
> -Wl,--enable-auto-image-base \
> -Wl,--out-implib,libplplotf77d.dll.a
> #Create main programme which uses the shared library
> g77 tstarg.f -o tstarg libplplotf77d.dll.a
> 
> I don't know the purpose of creating both the cyg*-9.dll form and lib*.dll.a
> form of the shared library, but I notice lots of Cygwin shared libraries
> seem to be organized that way.
> 

It is worth a try. I am not sure whether I will have time the coming 
few days, but I will try.

> Could you try this 3-part shared build method, please?  If there is some
> obvious improvement to this scheme that you prefer, please let me know your
> exact 3-part shared build steps so that I can report them to the Cygwin list
> along with the rest of the bug report (see below).
> 
> Here are some more semi-random experiments I suggest you try.  Most of these
> experiments assume there is some sort of error that exists for both static
> and shared linking, but which has no visible symptoms (by accident) for
> static linking.
> 
> Did you try dropping the external statement?  It is not needed on Linux, and
> in fact I don't see the point of it at all.  Would you use external for any
> other library function such as cos?  It might cause an error on Cygwin
> (which is only visible for shared linking). I would also drop the type
> statement for iargc since that is an intrinsic function.  The Cygwin fortran
> library may have the wrong intrinsic type for iargc implemented by mistake
> so I suggest your best bet is to let it figure out the intrinsic type for
> iargc itself rather than forcing a type that may not agree with the
> implementation.  Again, I am going by the way an invocation
> of the cos function should be handled.
> 
> What happens if you only have the iargc call and comment out the getchar
> call and vice versa?  I would like to know which fails or whether they
> both fail.
> 
> What happens if you comment out the getchar call and replace the iargc call
> by calculating cos(1.0)?  The linking and memory issues should be similar to
> iargc and getarg so if cos works and iargc and/or getarg do not, then that
> eliminates some possible explanations for the problem.
> 
> Once you tell me the exact 3-part commands you used to compile and link the
> shared library and compile and link the main routine, and also once you have
> the results of the second round of simple experiments and exact error
> messages, then I would be happy to write up the bug report for the Cygwin
> list unless you want to do that yourself.  I expect once they get such a
> detailed bug report with a simple example where they can verify the error
> for themselves, they will give us some quick action.
> 

I added the EXTERNAL statement merely to be accurate. For functions like
cos() and log10() this is not necessary, they are defined by the
standard.
But iargc and getarg are not. Oh well, these variations you suggest seem
worth looking into (or perhaps I should say: seem worth poking around 
with ... as I am completely at a loss when it comes to the inner regions
of the compilation and linking process)

Regards,

Arjen