# Hydra and static linking
**URL:** https://talk.remobjects.com/t/hydra-and-static-linking/18816
**Category:** Hydra
**Created:** [February 25, 2019, 2:56pm UTC](https://talk.remobjects.com/t/hydra-and-static-linking/18816 "2019-02-25T14:56:02Z")
**Posts on this page:** 12
**Page:** 1
### Author:  [@Santiago\_Burbano](https://talk.remobjects.com/u/Santiago_Burbano)
#### Post date: [February 25, 2019, 2:56pm UTC](https://talk.remobjects.com/t/hydra-and-static-linking/18816/1 "2019-02-25T14:56:02Z")
Hello,
our build servers still compile our applications with runtime packages. But because of the debugger issues with runtime packages and the new dll loading mechanism in Windows 10, we have started to build our application on development machines without runtime packages. This makes a huge difference for debugging purposes.
Today by chance I opened the ‘Hydra Project Package Settings’ and the following line caught my attention:
> “Hydra Applications need to be built with Packages”.
What is the reason for this? So far statically compiling Hydra into our app has been working fine for us.
Thank you!
---
### Author:  [@EvgenyK](https://talk.remobjects.com/u/EvgenyK)
#### Post date: [February 25, 2019, 3:10pm UTC](https://talk.remobjects.com/t/hydra-and-static-linking/18816/2 "2019-02-25T15:10:53Z")
Hi,
Hydra should be built with runtime packages only if you pass Delphi objects (i.e. descendants of TObject), etc between host and plugins.
If you don’t need to pass Delphi objects, host and plugins can be built w/o runtime packages.
in this case, VCL plugins should export only `HYGetCrossPlatformModule` method and not `HYGetModuleController name name_HYGetModuleController` method.
FMX plugins should export both functions in any way
```auto
exports
HYGetCrossPlatformModule,
HYGetCrossPlatformModule name name_HYFMGetModuleController;
```
---
### Author:  [@Santiago\_Burbano](https://talk.remobjects.com/u/Santiago_Burbano)
#### Post date: [February 25, 2019, 3:44pm UTC](https://talk.remobjects.com/t/hydra-and-static-linking/18816/3 "2019-02-25T15:44:30Z")
Thanks for the info!
We actually use plenty of Delphi Objects that inherit from **THYFakeIDispatch** and implement **IHYCrossPlatformInterface**.
So far we have not noticed any problems. What type of problems should we then expect when statically linking Hydra and passing Delphi objects between C# and Delphi?
Thanks!
---
### Author:  [@EvgenyK](https://talk.remobjects.com/u/EvgenyK)
#### Post date: [February 25, 2019, 4:02pm UTC](https://talk.remobjects.com/t/hydra-and-static-linking/18816/4 "2019-02-25T16:02:04Z")
you will catch problems only if delphi objects are passed as is in interfaces like
```auto
IMyInterface = interface(...)
..
procedure test(param1: TStringList); // << delphi object is used here
end;
```
* * *
if objects are passed as interfaces, like
```auto
IMyInterface = interface(...)
..
procedure test(param1: ISecondInterface);
end;
```
it will work w/o any issues.
ofc, `ISecondInterface` also shouldn’t use delphi objects as parameters.
---
### Author:  [@Santiago\_Burbano](https://talk.remobjects.com/u/Santiago_Burbano)
#### Post date: [February 25, 2019, 4:06pm UTC](https://talk.remobjects.com/t/hydra-and-static-linking/18816/5 "2019-02-25T16:06:02Z")
That is something we do not do.
So we are safe with static linking. 🙂
Just for curiosity what type of problem would you encounter in such a case, would it be a compile time or runtime error?
Thanks!
---
### Author:  [@EvgenyK](https://talk.remobjects.com/u/EvgenyK)
#### Post date: [February 25, 2019, 4:12pm UTC](https://talk.remobjects.com/t/hydra-and-static-linking/18816/6 "2019-02-25T16:12:50Z")
this is runtime error.
```auto
//SAssignError = 'Cannot assign a %s to a %s';
procedure TPersistent.AssignError(Source: TPersistent);
..
raise EConvertError.CreateResFmt(@SAssignError, [SourceName, ClassName]);
end;
```
for `IMyInterface` interface, it will be `Cannot assign a TStringList to a TStringList`
---
### Author:  [@chrisroyal](https://talk.remobjects.com/u/chrisroyal)
#### Post date: [June 28, 2020, 6:26am UTC](https://talk.remobjects.com/t/hydra-and-static-linking/18816/7 "2020-06-28T06:26:34Z")
Hi, I’m trying to develop an RO Server that supports Hydra RO Service plugins, and I don’t want to build with runtime packages. I tried what you suggested and changed the exports section as per your suggestion, only export `HYGetCrossPlatformModule`. But when loading the dll plugin I get a hydra error that my dll is not a valid hydra module.
What am I doing wrong here?
I’m using Hydra 4
---
### Author:  [@claudio.piffer](https://talk.remobjects.com/u/claudio.piffer)
#### Post date: [June 28, 2020, 7:28am UTC](https://talk.remobjects.com/t/hydra-and-static-linking/18816/8 "2020-06-28T07:28:19Z")
Hi
just a question only for understand. Why don’t you want to use runtime packages? I use it’s in server and client side without problems from many years. Debug is not a problem. The dll’s and executable are very small and in client side I use all devepress suite in all plugin modules and work very fine. I created my custom runtime package for every macro area: RTL and VCL are one package, RO/DA/HY are one package ecc ecc so I always have control over the package that I distribute
---
### Author:  [@chrisroyal](https://talk.remobjects.com/u/chrisroyal)
#### Post date: [June 28, 2020, 8:08am UTC](https://talk.remobjects.com/t/hydra-and-static-linking/18816/9 "2020-06-28T08:08:15Z")
Hi,
I have also created my own runtime packages, for both server and client. But sometimes maintenance becomes a nightmare. What my plan is to keep client as is with runtime packages, but for server I wish for it to be more lightweight without having to maintain these packages too. And to be honest, at some point I will convert it to console or service so it will have none dependencies on VCL but still being able to use plugins to extend functionality or deploy for a completely different project.
---
### Author:  [@EvgenyK](https://talk.remobjects.com/u/EvgenyK)
#### Post date: [June 30, 2020, 10:18am UTC](https://talk.remobjects.com/t/hydra-and-static-linking/18816/10 "2020-06-30T10:18:45Z")
Hi,
> [@chrisroyal](#):
>
> What am I doing wrong here?
> I’m using Hydra 4
`THYModuleManager` should have `LoadUnmanagedCrossPlatformModule` method.
if your version of Hydra hasn’t this method then this possibility were added after your version of Hydra and you should update Hydra.
---
### Author:  [@chrisroyal](https://talk.remobjects.com/u/chrisroyal)
#### Post date: [March 30, 2021, 2:51pm UTC](https://talk.remobjects.com/t/hydra-and-static-linking/18816/11 "2021-03-30T14:51:46Z")
Hi,
I decided to give this approach another try, but before I proceed with upgrading to the latest Hydra version I want to be clear that it will be able to do what I’m trying to achieve.
So you mentioned that with LoadUnmanagedCrossPlatformModule method, .dll plugins can be loaded without the need for runtime packages for both host and plugins. Having this in mind, can I put in my host application the ROServer and HYModuleManager components and load plugin modules with RO and DA services? Will this work? Will both host and plugins share the same classes?
---
### Author:  [@EvgenyK](https://talk.remobjects.com/u/EvgenyK)
#### Post date: [March 30, 2021, 3:05pm UTC](https://talk.remobjects.com/t/hydra-and-static-linking/18816/12 "2021-03-30T15:05:55Z")
Hi,
> [@chrisroyal](#):
>
> So you mentioned that with LoadUnmanagedCrossPlatformModule method, .dll plugins can be loaded without the need for runtime packages for both host and plugins. Having this in mind, can I put in my host application the ROServer and HYModuleManager components and load plugin modules with RO and DA services? Will this work? Will both host and plugins share the same classes?
in case of RO/DA services, your host and plugin should be built with `DA_Server` run-time package (of course, `RO_Core`, `RO_Server`, `DA_Core` packages are also required)
I can recommend to install [.1267 build](https://talk.remobjects.com/t/hydra-vnext-new-features/23813/3).
it allows to create RO/DA service plugins w/o Hydra\_VCL run-time package.
also it contains the `Remoting SDK Modular Server` sample. it’s almost the same as you want.