News:

Masm32 SDK description, downloads and other helpful links
Message to All Guests

Main Menu

Pelle's Forum

Started by dedndave, December 28, 2012, 04:42:08 AM

Previous topic - Next topic

MichaelW

Quote from: jj2007 on January 19, 2013, 04:08:05 AM
- PeView reveals that the members are all decorated, like _imp_gsl_matrix_alloc, _imp_matrix_set etc

Which indicates that it's an import library. GSL is not available as a static library?
Well Microsoft, here's another nice mess you've gotten us into.

dedndave

it is, now, thanks to Erol   :biggrin:

japheth

Quote from: dedndave on January 19, 2013, 06:19:05 AM
it is, now, thanks to Erol   :biggrin:

No, it's an import library, as MichaelW did tell already.

And even that creation of an import library wasn't needed, because the package already contains both static libs ( "libsl.a" ) and import libs ( "libsl.dll.a" ), AFAICS.



jj2007

Quote from: japheth on January 19, 2013, 06:32:53 AMthe package already contains both static libs ( "libsl.a" ) and import libs ( "libsl.dll.a" ).

It does indeed contain these files. How can they be used in PellesC? Sorry if these are stupid questions, but until now my lib files all ended with .lib ;-)

The source compiles fine with the newly created *.lib files but it asks for the presence of the DLLs. And the exe crashes in various places. It's not my source, I just have the honorable task to port it from a Unix machine to Windows...

japheth

Quote from: jj2007 on January 19, 2013, 06:41:25 AM
It does indeed contain these files. How can they be used in PellesC? Sorry if these are stupid questions, but until now my lib files all ended with .lib ;-)

In the MS world, libraries end with .lib, and in *nix they start with lib* and end with .a.

They both are COFF ARchives, buth sometimes with subtle differences, that make this and that tool crash if feeded with something from the "wrong" world.

The import files should be usable in any case, but static libs may require a certain static CRT - and I don't know ( and seriously doubt ) whether PellesC is the best option here.

Quote
The source compiles fine with the newly created *.lib files but it asks for the presence of the DLLs. And the exe crashes in various places. It's not my source, I just have the honorable task to port it from a Unix machine to Windows...

Good luck!

Vortex

Hi Jochen,

I'd like to convert \Masm32\PellesC\GSL\bin\libgsl-0.dll to a static library, \Masm32\PellesC\GSL\lib\libgsl-0.lib

Sorry if I misunderstand : you would to create a static library from a DLL?

MichaelW

I downloaded the package, installed it, copied libgsl.a to the directory of my previous cygwin/gsl test, and changed the relevant includelib statement in my test code to:

includelib libgsl.a

And assembled and linked the test app, and the only problem I can see is at the end of pass1:

libgsl.a(infnan.o) : error LNK2001: unresolved external symbol ___fpclassify
test.exe : fatal error LNK1120: 1 unresolved externals

Details in the attachment.

Well Microsoft, here's another nice mess you've gotten us into.

jj2007

Quote from: Vortex on January 19, 2013, 07:16:18 AM
Hi Jochen,

I'd like to convert \Masm32\PellesC\GSL\bin\libgsl-0.dll to a static library, \Masm32\PellesC\GSL\lib\libgsl-0.lib

Sorry if I misunderstand : you would to create a static library from a DLL?

Hi Erol,

Well, yes and no: The dll to lib version compiles at least, using your tools, the "use .a directly" version suggested by Japheth and Michael fails with Unresolved external symbol '__imp___iob' - there are half a Million Google hits for this particular iob error message, so I am in good company :biggrin:

GSL in MasmBasic works perfectly, but higher forces [i.e. colleagues who are not proficient in assembler] oblige me to use C. The usual mess :(

Vortex

Hi Jochen,

msvcrt.dll exports a function named _iob  :

\masm32\bin\dumpbin /EXPORTS C:\WINDOWS\system32\msvcrt.dll | find "iob"
        113   6F 0000F207 __iob_func
        136   86 0000F207 __p__iob
        320  13F 0004FC80 _iob


type \masm32\lib\msvcrt.lib | find "iob"
___p__iob
__imp____p__iob
__imp___iob
__iob
___p__iob
__imp____p__iob
__imp___iob
__iob
__p__iob
__imp____p__iob
_iob
__iob
__imp___iob


jj2007

Quote from: Vortex on January 19, 2013, 08:29:06 AM
Hi Jochen,

msvcrt.dll exports a function named _iob  :

Yes, adding \masm32\lib\msvcrt.lib to linker commandline helps :t
It boosts the exe from 80k to well over 1MB, too ;-)

MichaelW

When I got back to the static lib test it occurred to me to add a dummy procedure to my assembly module:

__fpclassify proc C
    ret
__fpclassify endp


And the build then succeeded and the EXE ran apparently normally. Since the DLL I tested previously worked OK, the problem would appear to be with that particular build of the library.

IIRC the iob components are for file streams, and are normally managed entirely by the CRT.

And in the DOS days, and IIRC, the Microsoft linker treated the libraries differently depending on where you included them on the Link command line, specifically, in the library section or in the object module section. Although I can't recall which is which ATM, one location caused Link to include everything, and the other caused it to include only what was referenced.


Well Microsoft, here's another nice mess you've gotten us into.

dedndave

i don't remember ever trying a library as a module on the old linker
but, i used them as libraries, and only what was referenced was linked

jj2007

Thanks to everybody for your help :icon14:
Here is the source of a test trying to get a random value - it fails with an exception:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <gsl_randist.h>
#include <gsl_cdf.h>
#include <gsl/gsl_errno.h>
#include <gsl/gsl_matrix.h>
#include <gsl/gsl_rng.h>
//#include <gsl\gsl_linalg.h> //JJ

int main(int argc, char *argv[]) {
      const gsl_rng_type * Ra;
   gsl_rng * r;
   gsl_rng_env_setup();
   Ra = gsl_rng_default;
__asm int 3;
   r = gsl_rng_alloc (Ra); //FAILS - debugging shows it should be a POINTER to gsl_rng_default
}


I tried Ra = * gsl_rng_default and variants but that throws errors. The version above compiles fine but crashed inevitably in gsl_rng_alloc...

I wonder if I misread the documentation of gsl_rng_alloc here...

Quote18.3 Random number generator initialization
— Function: gsl_rng * gsl_rng_alloc (const gsl_rng_type * T)

    This function returns a pointer to a newly-created instance of a random number generator of type T. For example, the following code creates an instance of the Tausworthe generator,

              gsl_rng * r = gsl_rng_alloc (gsl_rng_taus);

Attached the PellesC project, with lib files constructed with the Vortex tools. Two missing dlls are available here - scroll down to Download, binaries.

qWord

MREAL macros - when you need floating point arithmetic while assembling!

MichaelW

I don't currently have Pelle's C set up, so I used the Microsoft VC++ Toolkit 2003 compiler. I used the static library from the GSL installation, without renaming it. The only anomaly I encountered was several warnings:

/out:test.exe
libgsl.a
test.obj
libgsl.a(default.o) : warning LNK4217: locally defined symbol __iob imported in
function _gsl_rng_env_setup
libgsl.a(error.o) : warning LNK4049: locally defined symbol __iob imported
libgsl.a(stream.o) : warning LNK4049: locally defined symbol __iob imported

Well Microsoft, here's another nice mess you've gotten us into.