Author Topic: Pelle's Forum  (Read 29330 times)

MichaelW

  • Global Moderator
  • Member
  • *****
  • Posts: 1196
Re: Pelle's Forum
« Reply #30 on: January 19, 2013, 06:01:52 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

  • Member
  • *****
  • Posts: 8828
  • Still using Abacus 2.0
    • DednDave
Re: Pelle's Forum
« Reply #31 on: January 19, 2013, 06:19:05 AM »
it is, now, thanks to Erol   :biggrin:

japheth

  • Guest
Re: Pelle's Forum
« Reply #32 on: January 19, 2013, 06:32:53 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

  • Member
  • *****
  • Posts: 12691
  • Assembler is fun ;-)
    • MasmBasic
Re: Pelle's Forum
« Reply #33 on: January 19, 2013, 06:41:25 AM »
the 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

  • Guest
Re: Pelle's Forum
« Reply #34 on: January 19, 2013, 06:54:02 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

  • Member
  • *****
  • Posts: 2674
Re: Pelle's Forum
« Reply #35 on: January 19, 2013, 07:16:18 AM »
Hi Jochen,

Code: [Select]
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

  • Global Moderator
  • Member
  • *****
  • Posts: 1196
Re: Pelle's Forum
« Reply #36 on: January 19, 2013, 07:47:33 AM »
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

  • Member
  • *****
  • Posts: 12691
  • Assembler is fun ;-)
    • MasmBasic
Re: Pelle's Forum
« Reply #37 on: January 19, 2013, 08:19:15 AM »
Hi Jochen,

Code: [Select]
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

  • Member
  • *****
  • Posts: 2674
Re: Pelle's Forum
« Reply #38 on: January 19, 2013, 08:29:06 AM »
Hi Jochen,

msvcrt.dll exports a function named _iob  :

Code: [Select]
\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

Code: [Select]
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

  • Member
  • *****
  • Posts: 12691
  • Assembler is fun ;-)
    • MasmBasic
Re: Pelle's Forum
« Reply #39 on: January 19, 2013, 08:35:41 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

  • Global Moderator
  • Member
  • *****
  • Posts: 1196
Re: Pelle's Forum
« Reply #40 on: January 19, 2013, 03:16:41 PM »
When I got back to the static lib test it occurred to me to add a dummy procedure to my assembly module:
Code: [Select]
__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

  • Member
  • *****
  • Posts: 8828
  • Still using Abacus 2.0
    • DednDave
Re: Pelle's Forum
« Reply #41 on: January 19, 2013, 06:39:37 PM »
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

  • Member
  • *****
  • Posts: 12691
  • Assembler is fun ;-)
    • MasmBasic
Re: Pelle's Forum
« Reply #42 on: January 19, 2013, 07:29:35 PM »
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:

Code: [Select]
#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...

Quote
18.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

  • Member
  • *****
  • Posts: 1475
  • The base type of a type is the type itself
    • SmplMath macros
Re: Pelle's Forum
« Reply #43 on: January 19, 2013, 09:37:16 PM »
EDIT: Hier stand Misst
MREAL macros - when you need floating point arithmetic while assembling!

MichaelW

  • Global Moderator
  • Member
  • *****
  • Posts: 1196
Re: Pelle's Forum
« Reply #44 on: January 19, 2013, 09:46:10 PM »
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:
Code: [Select]
/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.