[clean-list] htoclean sorrows

[Matthew Bromberg]

Thank you for this information.  I have verified that the atlas .dll 
library files are definately in ccall format. No doubt all the
other C compatible blas libraries are in this format as well.  Now the 
strange thing
is that due to the limitations of the various library tools it is not 
really possible to get them into a stdcall format in what I'd
call a finite amount of time.  One could ask the question, how would you 
fix a third party .dll that uses a cdecl calling convention so that it 
works with clean?
One unpleasant possibility would be to write some C or possibly assembly 
code that loads the offending libraries dynamically using microsofts 
loadlibrary facility.
Presumably the windows dll that contains LoadLibrary could itself be 
loaded into clean since it will be in the stdcall format.  Personally I 
think I'll pass on
that effort.  It would be nice if I could load a static ccall library 
into clean since that could fix this problem as well. (How does clean 
load ccall object files?)

Here are the rather boring details of the stdcall conversion problem if 
anyone cares:

  The only way to enforce stdcall (without explicitly doing so in the 
source code) appears to be to let gcc build a default library that 
attempts to
export all the symbols, but this leads to undefined references so it 
won't build. (Most of the undefined
references are in various C standard libraries.)  The same 'feature' is 
present in microsoft's link tools. The fact that
the cygwin library dependencies need to be replaced with mingw, for 
performance and copyright issues, just complicates things.

Attempts to use --exclude-libs field  seems to fail when calling it 
through gcc, so that does not appear to fix the undefined or doubly defined
references. I have noted that the -mrtd flag or the -mno-rtd flag does 
not appear to change the calling convention during linking as well.  The 
way the final dll is normally built therefore, is through the inclusion 
of a  .def file. The .def file is built essentially by 'hand', with no 
calling information easily available, so the @ decoration can not be 
readily inferred.  Moreover it appears that there are no export 
declarations whatsoever in the sources so that cdecl  or ccall I should 
say defaults.  It is not even clear that using the @ decoration in the 
initial .def file would even work.

Diederik van Arkel wrote:
> On May 28, 2006, at 9:31 PM, SevenThunders wrote:
>
>>
>> I finally tried copying the _library file describing the entry points 
>> and the
>> dll to the
>> Clean System Files subdirectory.  This will actually allow the 
>> program to
>> link, but it crashes
>> after any launch attempts.  The library works fine linking to C 
>> programs and
>> I even got it to
>> work in Haskell.  But Haskell's foreign array syntax is abominable in my
>> opinion.
>
> Yep, _library files (currently) need to be in a Clean System Files 
> directory.
>
>>
>> I presume the problem occurs in how the .dll library is called.  The
>> declaration for the foreign function I use is of this form
>>
>>
>>
>> cblas_daxpy :: !Int !Real !{Real}  Int !{#Real} !Int -> Int ;
>
> should be: cblas_daxpy :: !Int !Real !{#Real}  !Int !{#Real} !Int -> 
> Int ;
> (missing unboxed annotation on the first array and strictness on the 
> second
> int argument)
>
> also I'd introduce an extra state arg with :V:I since fiddling with 
> the value
> of a void return type to force evaluation is rather ugly.
>
>> cblas_daxpy a0 a1 a2 a3 a4 a5  = code {
>>     ccall cblas_daxpy "IRAIAI:I"
>> }
>>
>>
>> The actual C header file declaration looks like
>> void cblas_daxpy(const int N, const double alpha, const double *X,
>>                  const int incX, double *Y, const int incY);
>>
>> I've tried every variation of this I could think of, including 
>> putting the P
>> as the first argument in the ccall string, as well as adding a 7'th 
>> state
>> argument and returning it using the :V:I trick.  Interestingly in the 
>> one
>> tiny .dll example that I got working, I did not need to use the P.  
>> The dll
>> was compiled via MS VC 2003.  My atlas blas library, however, is 
>> compiled
>> via gcc.
>>
>
> I'd regenerate the library using stdcall calling convention, this 
> avoids problems
> with compiler specific calling conventions.
>
> HTH,
>
> Diederik van Arkel
>
>>
>>
>>
>>
>> John van Groningen wrote:
>>>
>>>
>>> Matthew Bromberg wrote:
>>>> I am attempting to link to the acml BLAS .dll in a simple test of the
>> clean FFI.  I have a windows XP 64 amd x2
>>>> machine.
>>>> ...
>>>> Some things that are missing from this description are the fact 
>>>> that the
>> symbol format has an @number syntax appended to each symbol that is not
>> explained,
>>>
>>> A @number is appended for functions that use the stdcall calling
>>> convention.
>>> This calling convention is usually used for functions exported by a 
>>> dll.
>>> The number after @ is the total size in bytes (on the stack) of the
>>> arguments
>>> of the function. (4 for each int or pointer and 8 for each double).
>>>
>>>> and the menu path to the IDE  menus that permit the import of the 
>>>> symbol
>> file and the import of the DLL are tricky to find and frankly I can't be
>> sure I got it correct. Also there is no description of how to add the 
>> object
>> file.
>>>
>>> The text file that contains the exported functions of the .dll can
>>> be added in menu Project / Project Options after selecting Dynamic
>>> Libraries
>>> and button Append. And object file can be added in the same dialog, 
>>> after
>>> selecting Extra Objects and button Append.
>>>
>>> Instead of using this dialog, you can add the files by moving the 
>>> files to
>>> the 'Clean System Files' folder, and adding the following lines to a 
>>> .icl
>>> module:
>>>
>>> import code from "cmatrix.obj"
>>> import code from library "libacm_library"
>>>
>>> The IDE will then search all the 'Clean System Files' in the project 
>>> for
>>> these
>>> files, and pass the files to the linker.
>>>
>>>> Here is my import file acml_library:
>>>> libacml_dll.dll
>>>> daxpy at 6
>>>
>>> daxpy has 5 integer or pointer arguments and 1 double argument, so
>>> 5*4+1*8=28 bytes for the arguments. The label name is therefore 
>>> daxpy at 28.
>>>
>>> You can use the dumpbin command line tool of visual c to list the
>>> names of the exported symbols of the dll, for example:
>>>
>>> dumpbin /exports libacm.dll
>>>
>>>> ..
>>>> y :: *{#Real}
>>>> y = {1.0, 2.0, 3.0, 4.0}
>>>> ..
>>>> Start :: (*{#Real}, Int)
>>>> Start
>>>> #! nlen = rmac  2.0 x  y
>>>> = (y, nlen)
>>>>
>>>
>>> The Start function contains 2 calls of function y, so you won't see
>>> the result of rmac. Moving y to Start prevents this:
>>>
>>> Start
>>>     # y = {1.0, 2.0, 3.0, 4.0}
>>>     #! nlen = rmac 2.0 x y
>>>     = (y,nlen)
>>>
>>> It would be better to let rmac yield the computed array.
>>>
>>> Kind regards,
>>>
>>> John van Groningen
>>> _______________________________________________
>>> clean-list mailing list
>>> clean-list at science.ru.nl
>>> http://mailman.science.ru.nl/mailman/listinfo/clean-list
>>>
>>>
>> -- 
>> View this message in context: 
>> http://www.nabble.com/htoclean+sorrows-t1598541.html#a4602103
>> Sent from the Clean forum at Nabble.com.
>>
>> _______________________________________________
>> clean-list mailing list
>> clean-list at science.ru.nl
>> http://mailman.science.ru.nl/mailman/listinfo/clean-list
>
>