coco_vc
16th March 2006 13:31 UTC

Library.nsh and the docu
Hi all,

I plan to have my installer script built on Linux for getting a Windows binary. I need to use the Library.nsh features and in the docu for Library.nsh I read "Note that you can only compile scripts using this system on Windows systems. It is not possible to compile on Linux etc.".
I don't have any Linux to test this so I'll ask here: this statement doesn't really suggest that you can't build a Windows binary on a Linux system if Library.nsh calls have been used right? (I assume that statement is trying to state that a linux binary can't be obtained if Library.nsh feature are used, but I want to be 100% sure about this.)

Thx,
Viv

kichik
16th March 2006 18:09 UTC

It does state that you can't use Library macros on Linux. The Library macros need to read version information and type library version information from files. While version information can probably be easily read using the already available resource editor class, reading type library version information requires some work.

coco_vc
16th March 2006 20:39 UTC

Hi kichik,

Thanks for your answer, but I still am not sure if I have a problem or not. So I rephrase the question in order for you to be able to answer just a yes or no (maybe I'm just too dumb or too tired now):
If I use Library.nsh features/calls in my script can I then successfully build a Windows binary on a Linux machine using NSIS?

Thx,
Viv

Comm@nder21
16th March 2006 20:43 UTC

as stated in the docs:
NO! unfortunately not.

it would require to alter the whole library.nsh, if even possible...

coco_vc
17th March 2006 11:38 UTC

Ok, then what can I do in case I need the following 2 features:
- build a windows installer on a Linux system
and
- use the Library calls (b/c I need to update dlls in-use)
?

Thx,
Viv

kichik
17th March 2006 11:52 UTC

You can modify Library.nsh a bit so it won't use LibraryLocal.exe. It won't work with type libraries and will fail if the DLL doesn't contain version information, but I guess it's better than nothing.

coco_vc
17th March 2006 14:14 UTC

Thanks kichik,

Another way: I think in case it's mandatory to build on a Linux system that I could also use the File, Delete, Rename calls with /REBOOTOK flag instead of using Library calls, for my dlls that don't need to be registered and are not shared right? I could somehow do an update of an in use dll with these function without having Library call correct?

Thx,
Viv

kichik
17th March 2006 14:17 UTC

Yes, you can use UpgradeDLL which does just that. It also uses GetDLLVersionLocal like the new Library.nsh version I've attached above.

The problem with Linux and the Library is only with the version information. If you get rid of it, or put some limits on what can be done, it can be used.

coco_vc
17th March 2006 14:59 UTC

Or, I could use Library calls and use wine on Linux to build the script. I'll have to see for one of these solutions ...

Thx,
Viv

coco_vc
17th March 2006 16:37 UTC

btw, where can I find some docu about UpgradeDLL? I found in the installed package the UpgradeDLL.nsh but couldn't find any docu about this one.
Would I need for using UpgradeDLL the dll to have version information?

Thx,
Viv

kichik
17th March 2006 16:46 UTC

It needs version information but you can use it as a script example.

coco_vc
17th March 2006 18:19 UTC

Thx kichik.

And where could I find some UpgradeDLL docu?

Thx,
Viv

kichik
17th March 2006 19:48 UTC

There's none. It's deprecated. But the code is pretty short and self explanatory.

stb
20th March 2006 08:58 UTC

@coco_vc:

If the DLLs do not often change (e.g. MS DLLs) you could think about building some separate DLL installer package on Windows and using this helper package within your main installer (call it with "Exec"/"ExecWait" ...)

coco_vc
21st March 2006 16:15 UTC

kichik --

Thx for your changed library.nsh and your suggestions. I can't use your modified library.nsh file as one of my requirements is that anybody should be able to compile my script with the NSIS version specified in the docu, so I can't deploy the modified library.nsh also.
So I'll try to understand the UpgradeDLL and go that way. When I'll do so I might come back with other questions :)

btw, can't in future versions, library.nsh be modified so that when a specific param is specified no versioning is involved so the script would be then:
- compilable on linux system
and
- the call won't fail if the dll doesn't hold any version
?

stb --

The dll I'm talking about is changing with almost every version, so I will have to upgrade it along with the other binaries.

Thx,
Viv

kichik
21st March 2006 17:59 UTC

You can distribute the modified Library.nsh along with your script. If you use "!include Library.nsh", it'll first search the script's directory. You can also wait for version 2.16 which will include a modified Library.nsh.

coco_vc
22nd March 2006 09:44 UTC

> You can also wait for version 2.16 which will include a modified Library.nsh.

Are you saying that:
a) the NSIS version 2.16 will include your already modified Library.nsh (the one that fails if the dll doesn't have a version)?
or
b) it will actually include the change so that it will be compilable on linux and won't fail if the dll doesn't hold a version?

Thx,
Viv

kichik
23rd March 2006 18:07 UTC

It'll still fail for DLLs without version history. Only on Linux, of course.

coco_vc
10th April 2006 13:44 UTC

Hi *,

I noticed that indeed this was implemented for version 2.16 "Library now available on non-Windows platforms as well, although it requires the installed DLL to have version information" which is nice, but I want to ask something: isn't there any way, in future versions, to make it run (build windows binary on linux) even if the dll doesn't have a version? Like having one more param saying "I really don't care about version" and in that case no version checking to be done?

Thx,
Viv

coco_vc
26th June 2006 13:36 UTC

Hi kichik,

Don't want to be pushy, but I would like to know the answer to the above question. I mean would, in future versions, exist the possibility to: use Library calls and in the same time to build the code on linux, in case the version is not interesting at all?
For instance:

!insertmacro InstallLib DLL NOTSHARED REBOOT_NOTPROTECTED "Files\lolo.exe" "$SYSDIR\lolo.exe" "$SYSDIR" VERSION_NOT_CARE

kichik
30th June 2006 09:30 UTC

It's a feature that would be nice to have, so of course it should be in a future version. Which version is another question. You could speed up the process by submitting a patch for this.