flat assembler
Message board for the users of flat assembler.
![]() |
Author |
|
vid 19 Jun 2011, 17:48
.lib is just a bunch of .obj files put together into single file. It is useful for bigger libraries, where you place each function to separate .obj file, and linker only includes those which are used in final project. If you don't need this and want to always include everything, you can simply use .obj and link it with your project.
I wrote several examples long time ago. Look at HLL section of this forum, something like "Mixing C and asm". Maybe it's in examples part of the site too. |
|||
![]() |
|
bobsobol 19 Jun 2011, 21:01
Yes, I'd seen those examples before I posted this thread vid, and checked out the interesting stuff on your site. ^^ (can find the zip on the examples page, but can't find the topic now.)
![]() I'd gathered .lib was a collection of .obj, and what the compiler would do with different objects in the library. That's what I want. A library of code which I can include in VC projects with lots of routines (like my own mini CRT for example) that each project may only use part of. If making a lib is too hard from FASM, and including multiple .obj files would achieve the same thing, I can do that... but then I'd want to produce multiple .obj files from the FASM source, (as various routines may rely on, or share data with each other) and I don't know how to build a FASM project to multiple target files either. Best info I could find was in this thread Format the ASM like:- Code: format MS COFF public StdOut as '_StdOut@4' extrn '__imp__GetStdHandle@4' as GetStdHandle:dword extrn '__imp__WriteFile@20' as WriteFile:dword extrn '__imp__lstrlenA@4' as lstrlen:dword Include '%fasminc%\win32a.inc' section '.code' code readable executable proc StdOut,lpszText hOutPut dd ? bWritten dd ? sl dd ? enter invoke GetStdHandle,STD_OUTPUT_HANDLE mov [hOutPut], eax invoke lstrlen,[lpszText] mov [sl],eax lea eax,[bWritten] invoke WriteFile,[hOutPut],[lpszText],[sl],eax,NULL mov eax,[bWritten] return endp I would have thought the section would need to have "writeable" for the code to even work but... "who am I to blow against the wind." link with:- Code: lib /OUT:console.lib Object1.obj Object2.obj But how do I get FASM to produce "Object1.obj" and "Object2.obj" from one source file? Or can the object file contain lots of routines that the compiler will link only what is needed... or can I include lots of object files in a .h which, only those which are actually used in the final program end up included in the executable? |
|||
![]() |
|
vid 19 Jun 2011, 21:54
No, linker always takes entire .obj file whenever any symbol from it is referenced[1]. You do have to compile every object file separately, and unless you want to use some kind of trickery, you should have separate .asm file for every .obj target. Then, merge produced .objs to .lib file, and then create single .h for your .lib. Linker doesn't care where some symbol is declared (.h file in your case), it only links every .obj file from which any symbol is referenced.
[1] I think there is a mechanism for having multiple independent optionally-linked things in same .obj, called something like COMDAT, but I don't know anything about it. |
|||
![]() |
|
bobsobol 20 Jun 2011, 06:19
Your information is giving me ideas for such "trickery". ^^
If I use "proc" macro, then only used procedures are included in an object file? So I can keep routines of similar liniage in a single file, or at least a primary code file and optional INCludes. I can then INClude that file in several ASM files which import only 1 to a few co-dependant routines from it, (init, manipulate, despose type interdependence) and export them in the destination object file. A batch script (or Perl, or similar) to compile all ASM files in a directory would produce my "collection of .obj files", and could then pass each of them in as a list to a single "lib.exe" command to produce the .lib file. My .h file to associate C constants and import descriptions from the .lib can almost be an "automated-translation" from the ASM files which created the object files in the first place. Then I can produce my general purpose runtime library of routines, optimised with the precision hand crafting of x86 which we all love. ^_^ One thing I may have to think carefully on, is co-dependant routines which may / will appear in multiple .obj files, and the likelihood of those then appearing multiple times in the same executable when linked together... but it's a start idea. I'm guessing I could build up in waves from very low level objects to the final exposed calls, and simply don't expose the very low level stuff from the .h file... or, do, just in case it can be useful for the high level code. |
|||
![]() |
|
vid 20 Jun 2011, 16:19
Yep, that's the sort of trickery I was talking about. It gets job done, but isn't exactly nice should anyone else ever touch your sources.
Quote: One thing I may have to think carefully on, is co-dependant routines which may / will appear in multiple .obj files, and the likelihood of those then appearing multiple times in the same executable when linked together... And that's sort of problems using "custom trickery" usually causes ![]() |
|||
![]() |
|
bobsobol 21 Jun 2011, 09:30
Well, thank you for that vid.
Thanks to your responses, I now know 'how' and why it's such a PITFA. Would be really nice if we could get the FASM linker to link to a .lib "collection of object" in the first place, as it could easily be very smart about the dependabilities. ^_^ Code: format MS COFF LIB ![]() |
|||
![]() |
|
vid 21 Jun 2011, 10:00
IMHO someone developing larger project (eg. a proper library) should be capable of using other tools than just FASM. And there are plenty of tools existing which can create .lib just fine, so there's no need to duplicate this functionality in FASM. Problem of FASM is that's it is not designed to be used in cooperation with other tools. That's an advantage if you want ultra-easy asm-only project setup, but great disadvantage if you want to combine several tools for your project.
PS: My old FASMLIB was built into DLL, several several .obj formats, several .lib formats, and it was also usable by directly including by sources "the FASMy way" - all of that in versions for several different OSes. Been there, done that, it worked but it wasn't very nice. |
|||
![]() |
|
< Last Thread | Next Thread > |
Forum Rules:
|
Copyright © 1999-2025, Tomasz Grysztar. Also on GitHub, YouTube.
Website powered by rwasa.