I am trying to make a static 64bit library.
My parameters are for ML64 and LIB.EXE are
REM Assemble
\masm64\bin64\ml64.exe /c Modules\_add.asm
\masm64\bin64\ml64.exe /c Modules\_sub.asm
REM Compile object files into lib
\masm64\bin64\LIB.EXE *.obj /out:%appname%.lib
PROBLEM
When I look obj file with a hex editor, i have realized that my path to obj file is also included.
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000080 00 00 00 00 00 00 00 00 40 00 10 42 48 89 4D 10 ........@..BH‰M.
00000090 48 89 55 18 48 8B 45 10 48 8B 5D 18 48 03 C3 C3 H‰U.H‹E.H‹].H.ÃÃ
000000A0 04 00 00 00 F1 00 00 00 91 00 00 00 56 00 01 11 ....ñ...'...V...
000000B0 00 00 00 00 43 3A 5C 55 73 65 72 73 5C 41 64 6D ....C:\Users\Adm \
000000C0 69 6E 69 73 74 72 61 74 6F 72 5C 44 6F 77 6E 6C inistrator\Downl | I don't want
000000D0 6F 61 64 73 5C 4D 41 53 4D 33 32 2D 46 4F 52 55 oads\MASM32-FORU | thıs path info
000000E0 4D 5C 55 73 65 72 73 5C 62 6C 75 65 64 65 76 69 M\Users\bluedevi |
000000F0 6C 5C 41 72 69 74 68 4C 69 62 5C 5F 61 64 64 2E l\ArithLib\_add. |
00000100 6F 62 6A 00 37 00 3C 11 03 02 00 00 D0 00 00 00 obj.7.<.....Ð... /
00000110 00 00 00 00 00 00 0E 00 21 00 8D 7B 00 00 4D 69 ........!..{..Mi
00000120 63 72 6F 73 6F 66 74 20 28 52 29 20 4D 61 63 72 crosoft (R) Macr
00000130 6F 20 41 73 73 65 6D 62 6C 65 72 00 00 00 00 00 o Assembler.....
00000140 40 63 6F 6D 70 2E 69 64 8D 7B 03 01 FF FF 00 00 @comp.id.{..ÿÿ..
Then when I run LIB.EXE and create a static library files, that library file also includes this path information.
QUESTION
Which command line parameters should I use to make ML64 or LIB.EXE not to include this path info. I have checked ML64 (https://learn.microsoft.com/en-us/cpp/assembler/masm/ml-and-ml64-command-line-reference?view=msvc-170) command line reference and LIB.EXE (https://learn.microsoft.com/en-us/cpp/build/reference/running-lib?view=msvc-170) pages, unfortunately I couldn't find a proper solution?
.debugSS is in object-file and lib.exe (link.exe) just store it.
Hi bluedevil,
The path data does occur in the OBJ module but it does not appear in the final binary. Why is this a problem ?
If you are distributing the OBJ modules, build the OBJ files in a different directory so that the name does not tell anyone anything useful.
Would zeroing out the path information cause any detrimental effects? If not would be a simple matter to take care of. Either in a hex editor or write a simple program to do the job. I'm not at my computer just now, else I would check for myself. :biggrin:
Try building from main module file directory.
Quote from: zedd151 on October 07, 2022, 09:43:16 AM
Would zeroing out the path information cause any detrimental effects? If not would be a simple matter to take care of. Either in a hex editor or write a simple program to do the job. I'm not at my computer just now, else I would check for myself. :biggrin:
A bit later, I tested my theory...
After zeroing out the path in both object files, the .lib file still gets created without issue and no path information is written to it. I just tested it. But be sure not to zero out anything after or before the path information.
I modified the batch file in 2nd zip file to not recreate the object files, but to only create the lib file from them. First zip file is only the resulting .lib fileSo, we both learned something new today. :azn: To test this for yourself, (from 2nd zip) delete lib file, inspect both .obj files (see that no path there) then run the batch file and inspect the resulting lib file with a hex editor (no path there either). :biggrin: Attachment removed as it has served its purpose
I have not tested the lib file after the modification above bluedevil. I will leave the tesing up to you. Let me know that it works okay or not. :tongue: Im running 32 bit machine at the moment (but can still use 32 bit versions of ml64,link & lib) :biggrin:
btw, why
mov a, rcx
mov b, rdx
mov rax, a
mov rbx, b
add rax, rbx
mov rax, rcx
mov rbx, rdx
add rax, rbx
Less code and a tad faster, especially if run multiple times in a loop
Okay, curiosity got the better of me so heres a test file. Testing the lib I created above, switched over to 64 bit for this. Success!
include \masm64\include64\masm64rt.inc
include ArithLib.Inc
includelib ArithLib.lib
.code
entry_point proc
invoke _add, 32, 64
invoke MessageBox, 0, str$(rax), 0, 0
invoke ExitProcess, 0
ret
entry_point endp
end attachment removed as it has served its purpose
Using SUBST is an easy way to shorten paths to obj-file.
Many use it for masm32/masm64 too.
Quote from: TimoVJL on October 07, 2022, 08:10:11 AM
.debugSS is in object-file and lib.exe (link.exe) just store it.
@TimoVJL so what is the way not to add this
debug$S statement in obj file?
Quote from: hutch-- on October 07, 2022, 09:32:04 AM
The path data does occur in the OBJ module but it does not appear in the final binary. Why is this a problem ?
@hutch-- unfortunately final binary still has those path info inside, you can check that out by using a hex editor:
Form library file.
Offset(h) 00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
00000000 21 3C 61 72 63 68 3E 0A 2F 20 20 20 20 20 20 20 !<arch>./
00000010 20 20 20 20 20 20 20 20 31 36 36 35 30 38 38 34 16650884
00000020 37 36 20 20 20 20 20 20 20 20 20 20 20 20 20 20 76
00000030 30 20 20 20 20 20 20 20 32 32 20 20 20 20 20 20 0 22
00000040 20 20 60 0A 00 00 00 02 00 00 00 B4 00 00 02 D6 `........´...Ö
00000050 5F 73 75 62 00 5F 61 64 64 00 2F 20 20 20 20 20 _sub._add./
00000060 20 20 20 20 20 20 20 20 20 20 31 36 36 35 30 38 166508
00000070 38 34 37 36 20 20 20 20 20 20 20 20 20 20 20 20 8476
00000080 20 20 30 20 20 20 20 20 20 20 33 30 20 20 20 20 0 30
00000090 20 20 20 20 60 0A 02 00 00 00 B4 00 00 00 D6 02 `.....´...Ö.
000000A0 00 00 02 00 00 00 02 00 01 00 5F 61 64 64 00 5F .........._add._
000000B0 73 75 62 00 5F 73 75 62 2E 6F 62 6A 2F 20 20 20 sub._sub.obj/
000000C0 20 20 20 20 31 36 36 35 30 38 38 34 37 35 20 20 1665088475
000000D0 20 20 20 20 20 20 20 20 20 20 20 20 31 30 30 36 1006
000000E0 36 36 20 20 34 38 36 20 20 20 20 20 20 20 60 0A 66 486 `.
000000F0 64 86 03 00 DB 3B 3F 63 40 01 00 00 09 00 00 00 d†..Û;?c@.......
00000100 00 00 00 00 2E 74 65 78 74 24 6D 6E 00 00 00 00 .....text$mn....
00000110 00 00 00 00 14 00 00 00 8C 00 00 00 00 00 00 00 ........Œ.......
00000120 00 00 00 00 00 00 00 00 20 00 50 60 2E 64 61 74 ........ .P`.dat
00000130 61 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 a...............
00000140 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
00000150 40 00 50 C0 2E 64 65 62 75 67 24 53 00 00 00 00 @.PÀ.debug$S....
00000160 00 00 00 00 A0 00 00 00 A0 00 00 00 00 00 00 00 .... ... .......
00000170 00 00 00 00 00 00 00 00 40 00 10 42 48 89 4D 10 ........@..BH‰M.
00000180 48 89 55 18 48 8B 45 10 48 8B 5D 18 48 2B C3 C3 H‰U.H‹E.H‹].H+ÃÃ
00000190 04 00 00 00 F1 00 00 00 91 00 00 00 56 00 01 11 ....ñ...'...V...
000001A0 00 00 00 00 43 3A 5C 55 73 65 72 73 5C 41 64 6D ....C:\Users\Adm
000001B0 69 6E 69 73 74 72 61 74 6F 72 5C 44 6F 77 6E 6C inistrator\Downl
000001C0 6F 61 64 73 5C 4D 41 53 4D 33 32 2D 46 4F 52 55 oads\MASM32-FORU
000001D0 4D 5C 55 73 65 72 73 5C 62 6C 75 65 64 65 76 69 M\Users\bluedevi
000001E0 6C 5C 41 72 69 74 68 4C 69 62 5C 5F 73 75 62 2E l\ArithLib\_sub.
000001F0 6F 62 6A 00 37 00 3C 11 03 02 00 00 D0 00 00 00 obj.7.<.....Ð...
Folks, I have checked that nasm-created obj files do not have this path info by default. So I wonder if I can do it with ML64 or at least if I can do it in final binary: the lib file?
@zedd151 thank you, I am already aware of that technique. As a last option I will use that.
Quote from: HSE on October 07, 2022, 10:00:10 AM
Try building from main module file directory.
@HSE, can you expand this a little more? I think I couldn't manage that.
@bluedevil ok. Was not aware that you had tried it already. :biggrin:
I was also curious if it would work myself, as I did not know until I tried it.
I think, that debug$S is needed by linker for rich header ?
Quote from: TimoVJL on October 07, 2022, 06:37:18 PM
I think, that debug$S is needed by linker for rich header ?
I am ok if that path is in OBJ file. Problem is, I don't want that path info in my "release build" of static lib. And I couldn't find a way to do it from the ml64/lib parameters. Only LINK.EXE has parameter of "RELEASE". Can link.exe make static libs?
Have you tried using poasm rather than ml64 to create the .obj files...?
From here, doesnt add the path to the object files.
scratch that idea, unless poasm needs something that im missing. :undecided:
While poasm doesn't add the path strings to the .obj files, after creating the .lib file and linking the .lib file to a test program the test program crashed. No idea why as I don't have 64 bit debugger.
Quote from: zedd151 on October 07, 2022, 06:56:34 PM
Have you tried using poasm rather than ml64 to create the .obj files...?
From here, doesnt add the path to the object files.
Are you sure, because I couldn't. Can you share which parameters you used to assemble with poasm?
Hi bluedevil,
I have attached a simple console example that calls a couple of MASM64 library modules. They can be found in the OBJ module but do not appear in the EXE file. When you mention a STATIC library, that is a different matter, a library contains the data in the OBJ modules so it will be visible in a HEX editor.
I have never done it but you could try in the final library to replace the path with blanks so it cannot be read.
Just testing:
SUBST X: working folder
X:
ml64 foo.asm
in debug$S SECTION is X:foo.obj
Quote from: bluedevil on October 07, 2022, 07:04:18 PM
Quote from: zedd151 on October 07, 2022, 06:56:34 PM
Have you tried using poasm rather than ml64 to create the .obj files...?
From here, doesnt add the path to the object files.
Are you sure, because I couldn't. Can you share which parameters you used to assemble with poasm?
Didnt work here either, I tried it then revised that post.
but this is what I used..
\masm64\bin64\poasm.exe _add.asm
\masm64\bin64\poasm.exe _sub.asm
\masm64\bin64\lib.EXE _add.obj _sub.obj /out:test.libBut when linking test code to the .lib file, it doesnt work... the test program crashed, I don't have debugger for 64 bits. So couldn't check why it crashed
I dont know what parameters poasm needs as I am unfamiliar with it, but it didnt like '/c' so I removed that
The first solution that I offered seems to be the best I can come up with, manually zeroing out the path string in the object files.
I'm still learning some of this stuff myself. :biggrin:
Quote from: TimoVJL on October 07, 2022, 07:06:51 PM
Just testing:
SUBST X: working folder
X:
ml64 foo.asm
in debug$S SECTION is X:foo.obj
@TimoVJL thank you very much. You trick is awesome. So I only change my batch file and now there is no path info in both obj files and in the static lib file.
REM Clean command prompt screen
cls
set appname=ArithLib
REM Substitute working folder
subst Y: %cd%
Y:
REM Delete compiled files if exists
if exist %appname%.lib del %appname%.lib
if exist %appname%.res del %appname%.res
if exist %appname%.obj del %appname%.obj
REM Assemble
C:\masm64\bin64\ml64.exe /c Modules\_add.asm
C:\masm64\bin64\ml64.exe /c Modules\_sub.asm
REM Compile object files into lib
C:\masm64\bin64\LIB.EXE *.obj /out:%appname%.lib
dir %appname%.lib
REM Delete virtual drive
C:
subst Y: /D
pause
Even though my aim was to to this by adding "some" parameters to ml64 or lib.exe, I now see that this is not possible!
@zedd151 and @hutch-- guys poasm and polib makes reaaaaaally small files/ I loved that!
I have included the sources and edited batch files for both ml64 and poasm
let me celebrate (https://www.youtube.com/watch?v=0Zb8io5ncZo)this :eusa_dance: :cool:
Okay, great! Glad you have the issue reolved. I wasn't so sure about poasm as I have never used it, but knew it didnt add the path strings.
My test program crashed though after using a lib created via poasm/lib. As long as you have got it working though, its all good. :biggrin:
Quote from: zedd151 on October 07, 2022, 08:12:59 PM
Okay, great! Glad you have the issue reolved. I wasn't so sure about poasm as I have never used it, but knew it didnt add the path strings.
My test program crashed though after using a lib created via poasm/lib. As long as you have got it working though, its all good. :biggrin:
Static library is not working if I create with poasm and polib. But it is not important right now; beacuse my aim is to use MASM64 SDK. And the library which I created with MASM64 SDK is working :thumbsup:
Okay. I am very glad that you have found a solution that works for you, for the path issue. :biggrin:
For example put _add.asm and _sub.asm in ArithLib directory, not in a subdirectory.
Quote from: HSE on October 07, 2022, 10:19:01 PM
For example put _add.asm and _sub.asm in ArithLib directory, not in a subdirectory.
Unfortunately there is no difference. ML64.exe assembles the source with the path of the file, so interesting. And I couldn't find any parameters to override this!