shared library/ko: what changed

Revision 1 to 2. Removed lines have a minus sign; added lines have a plus sign.

Old	New		Line
1	1		공유 라이브러리는 공유 및 다양한 프로그램에서 사용할 수있는 컴파일 된 코드의 일부이며, 기능과 다른 프로그램에서 호출 할 수있는 절차를 제공합니다. (즉 실행에 연결되고 그것의 일부가된다) 또는 실행 가능한 정적 라이브러리 다르다. 공유 라이브러리는 명시 적으로 언급 된 경우를 제외하고는 두 리눅스 .so를 및 Windows 인 DLL, 같은 또는 "DLL", "유닉스 공유 라이브러리를"포함하는 것을 의미한다.
2	2
3	3		이 페이지 공유 라이브러리는 FPC와 함께 동작하는 방법을 문서화하려고합니다.즉 : 공유 라이브러리는 어떻게 작동하는지, 작동뿐만 아니라 델파이에서 공유라이브러리를 사용하는 방법을.
4	4
5	5		우리는 물론 합리적인 (요구 사항에 의해 제한 여러 플랫폼에서 작동하는)로 호환되도록 노력할 것입니다 그렇기 때문에, 델파이가 지원하는 폼의 간단한 스케치부터 시작합니다.
6	6
7	7		이 문서에서는 Kylix의 세부 사항을 표시하지 않습니다; 그들은 여전히 관련된 경우 카일릭스의 세부 정보를 추가 주시기 바랍니다.
8	8
9	9		## 델파이
10	10
11	11		Delphi to my knowledge knows three (or four) ways of dynamic linking.
12	12
13	13		1. create a standalone shared library. (compiling a library unit without "runtime packages" selected).
14	14		- This means the RTL will be linked into the shared library
15	15		- This also means the memory manager will be its own island. Using automated types in functions that communicate with it is not possible.
16	16		- Use of Classes is not possible: both program and shared library have their own copies of the VMT, which breaks e.g. is and as operators
17	17		2. create a standalone shared library. (compiling a library unit without "runtime packages" selected), but while using unit sharemem)
18	18		- Comparable with previous case but the memory manager is switched to COM compatible. This means other components/programs that also switch their memory manager to sharemem can call functions that use automated types, because it doesn't matter who returns the block to the COM memmanagement system.
19	19		- Note that AFAIK the COM memory manager is quite slow. This road is probably not desired unless you really want to mess with COM, or your componentization is more important than speed.
20	20		3. [[packages\|Library packages]] These are shared libraries for which all dependancies on the Pascal level are known (which units they contain and depend on), and can be treated as parts of the main program that reside in a DLL.
21	21		- The RTL is in a separate package (DLL), and both the main program and package use it. Therefore there is only one copy of any unit including system.
22	22		- This also means there is only one memory manager, at least for the main program and the packages it uses. IOW shared libs that are not a package can still use an own RTL and memory manager.
23	23		- A package can only depend on units in its own package or in other packages. (separate compilation requirement)
24	24		- Because no units are duplicated, there is only one copy of each VMT, making classes use transparent.
25	25		- Probably packages can also switch to sharemem, making it compatible with other systems using sharemem. Some way must be found to initialise sharemem as early as possible though (does Delphi do this? Possible test for this is to pass an ansistring created in a init section of a unit in a package to a different sharemem using shared lib that is not a package) to be determined
26	26
27	27		Besides these, Delphi can also generate DLLs that are ActiveX components. to be described/determined
28	28
29	29		Topics about library packages are mostly moved from this page to the separate [[packages]] article, to avoid confusing the discussion.
30	30
31	31		## Linker namespaces
32	32
33	33		One of the big problems with porting dynamic libraries from Windows (e.g. DLLs) to Linux and FreeBSD, is the fact that Windows and OS X have a linker namespace per module (as in, per shared lib or binary), with export tables carefully governing exported symbols, and Linux and FreeBSD only have one single linker namespace.
34	34
35	35		Specially in multi-language projects this is a problem.
36	36
37	37		I got some feedback on this from a FreeBSD hacker, who recommended to look into ELF visibility attribute, and/or API versioning:
38	38
39	39		- <http://gcc.gnu.org/wiki/Visibility>
40	40		- <http://people.freebsd.org/~deischen/symver/freebsd_versioning.txt>
41	41
42	42		Note that while the last URL is about FreeBSD, it mentions Linux doing the same.
43	43
44	44		## Sharemem implementation details
45	45
46	46		As said, sharemem switches the memory manager to a global one. Under Windows this is AFAIK the COM manager. On *nix a similar memmanager doesn't always exist (Gnome and KDE component architectures might have something similar), so this is not guaranteed.
47	47
48	48		One could probably simply have all programs use cmem, which could be a "level 0" implementation for everything that runs in this process.
49	49
50	50		I explicitely mention this because it might be necessary to impose an own initialisation order (independant of OS shared lib initialisation) to allow the main program to initialise units right after the RTL (system unit) initializations, but before other libs, e.g. a different memory manager.
51	51
52	52		## VMT duplication
53	53
54	54		The basic problem of VMT duplication is mostly support for the is parameter and similar methods of TObject and TClass like inheritsfrom. This is only solved for packages, IOW for the other two types named above, the is operator doesn't work across libraries/binaries.
55	55
56	56		In earlier discussions about packages, there was some confusion about this topic. People assumed that packages would somehow tap into the RTL VMTs in the main binary. I'm however pretty sure this is not the case, at least not in Delphi, since if you use packages, the RTL always is a package, too. Also, every dependency of a unit in a package must be in the same package or in a package it has a dependency on. This means a unit (and thus, the VMTs declared in it) only exists once in the greater program (main program + its packages)
57	57
58	58		## Initialization and finalization sections and RTL
59	59
60	60		(The initialization order of units in packages is moved to the packages page).
61	61
62	62		The problem with libraries is usually that libraries are initialized as a whole. This can lead to problems with plugin units modifying RTL behaviour (cwstrings, cmem, FV drivers etc)
63	63
64	64		For stand-alone libraries with internal copies of RTL to function, the RTL needs to be initialized, and the initialization section of the library needs to be called as well.
65	65
66	66		Roughly there are two options here:
67	67
68	68		- Use (e.g. on ELF platforms) the ABI .init and .fini sections or similar constructs in other binary formats.
69	69		- Leave the above initializers mostly empty sections, and enforce an own order using a set of own initializers and finalizers. The ELF init and fini sections merely register the real initializers.
70	70
71	71		Mixed forms are also possible, e.g. initialize standalone shared libraries via the initializer sections, but with packages use an own definition.
72	72
73	73		## 공유 Exe 메모리 매니저
74	74
75	75		Lars says: regarding a single memory manager for BPL style packages: what about using the executable and exporting its memory manager? I have had problems trying to use CMEM but have successfully shared the same memory manager using SetMemoryManager/GetMemoryManager tricks.
76	76
77	77		See <http://www.freepascal.org/contrib/delete.php3?ID=543> for an example of sharing memory between exe and dll without using CMEM. Powtils CGI library also uses this trick for dynpwu.pas so that ansistrings can be used without any sharemem or cmem unit. The memory manager is exported from the executable or a single library and shared with all the other DLL/EXE's that are connecting to the single module.
78	78
79	79		Marco's answer: First, library packages have more features than just shared memory managers. Unique VMTs (try to use the is operator in your example on a class created in the other lib/exe) and no need to handcraft proper initialization. One just groups units into libs, and the compiler does the rest. No special code required. So what must be done for (library) packages is different (and non competing) to the more general shared library case. And that is what this page is about.
80	80
81	81		From this general "shared library" case, a subdivision can be separated that has a shared memory manager.
82	82
83	83		Note that there can be a bunch of memory managers used for this, and multiple units that work like sharemem. Nearly any memory manager applies. However it is logical to reserve the "sharemem" unit name for the memory manager that is the most compatible for inter-process work on the given platform (COM on Windows, cmem on Unix). So, I'm talking about the default case here, which doesn't mean that other people can't roll their own.
84	84
85	85		Also, in-compiler (RTL) support must be as universal as possible, and also work for libraries that are not loadlibrary-ed, but autoloaded at binary startup, and not require handcoding e.g. initialization. Also it mustn't stand in the way of handcoded solutions (like the one you reference), in other words it must be overridable, since otherwise in-compiler (RTL) support would stand in the way of what people build on top of FPC.
86	86
87	87		It would be useful though, if somebody investigate if it is possible to call exported symbols from the binary from an autoloaded library (for the Tier 1 targets, Linux/FreeBSD - Windows - OS X). This because then a library could maybe indeed plug in the mother binary.
88	88
89	89		In short the first objective is to simply have a default scheme that works like Delphi's sharemem to put in the "sharemem" unit.
90	90
91	91		Marco, added later after some new insights
92	92
93	93		Moreover a difference is also if the units in the dll are accessed directly, or only over a separately (additionally) defined interface.
94	94
95	95		Lars says: Well another idea: instead of exporting the memory manager from the exe I was thinking about making a fpsharemem.dll that exports one single common FPC memory manager on each platform for all the programs and DLLs to use, instead of using CMEM. i.e. all units put fpsharemem.dll in their uses clause. In fact, that's actually what the demo does but instead of a separate fpsharemem.dll it is just inside that single DLL included with the demo and all the other code. i.e. why use CMEM if we can use freepascal memory manager? The freepascal mem manager is available on all platforms isn't it, as long as there is a FreePascal DLL that is created for each platform?
96	96
97	97		I guess to answer my own questions it must have to do with COM/IPC (inter process communication) issues/compatibilities. Well anyway, still a very interesting discussion. Doing it by hand the way I did was just a demo to show the concept in action and to prove to people that ansistrings and automated types can be used in regular old DLLs.
98	98
99	99		Marco: If you have to make one (thing? memory manager?) mandatory, make it cmem, because otherwise you might not be able to interface with some shared libs. If you can somehow make it user selectable it would be better. But keep in mind that it is already hard to pack two precompiled sets of units into a release (increasing to 200MB installed size or so), let alone more.
100	100
101	101		Roughly this scheme is what sharemem does, communication over COM/IPC to make sure that a second instance of a library doesn't instantiate its state twice. It avoids the DLL with the memmanager itself by using COM as memory manager. (Something that wouldn't work on Unix, since there is no such global memory manager).
102	102
103	103		I've thought about this in the past too, but once you start adding a few more things (like is operator support, and something end-user supportable for people that can't write a header to a DLL), you end up with effectively packages again. It is really not that much more, runtime, just a few tables to govern proper unit initialization.
104	104
105	105		## 델파이에서 변환
106	106
107	107		### dllproc
108	108
109	109		델파이는 윈도우즈 DLL의 DLLProc hook의 DLL entry point 접근이 가능하며 아래와 같다:
110	110
111	111		- DLL_PROCESS_ATTACH
112	112		- DLL_PROCESS_DETACH
113	113		- DLL_THREAD_ATTACH
114	114		- DLL_THREAD_DETACH
115	115
116	116		프리파스칼에서는 이기능들을 사용할 수 없고, 윈도우즈상에서 아래 3가지만 조작할 수 있다:
117	117
118	118		- Dll_Process_Detach_Hook
119	119		- Dll_Thread_Attach_Hook
120	120		- Dll_Thread_Detach_Hook
121	121
122	122		## FPC에서 공유라이브러리 사용
123	123
124	124		See the FPC documentation (to do: insert link). On Windows, the bitness of the program you are writing (e.g. 64 bit application) must match the bitness of the DLL you are using.
125	125
126	126		Debugging FPC libraries called by an FPC program: if you are using Lazarus:
127	127
128	128		- Open your library project
129	129		- Go to Run/Run Parameters, enter the full path of the application that uses your library in Launching Application
130	130		- Check the "Use launching application".
131	131		- Set the breakpoints as usual and Run the program.
132	132
133	133		### Initialization order
134	134
135	135		Warning: you should not initialize resources like a db engine that use LoadLibrary to load external libraries in `initialization` sections or finalize them in `finalization` (maybe only as last chance) because this is not supported by the underlying operating system. See [Issue \#26801](https://bugs.freepascal.org/view.php?id=26801).
136	136
137	137		## 다른언어 에서 FPC 라이브러리 사용
138	138
139	139		The possibility to create a shared library in FPC and being able to use it in other languages (typically but not limited to C/C++) is one of the key goals of having the idea of shared libraries.
140	140
141	141		Official documentation: FPC programmer's guide, chapter 12.
142	142
143	143		In general
144	144
145	145		- keep you library procedural; do not rely on OOP (Object-Oriented Programming)
146	146		- use simple types in the interface procedures, avoid usage of
147	147		- ANSI / Unicode strings (non OLE-bases). ShortStrings are ok.
148	148		- explicit dynamic strings (open arrays are ok)
149	149		- classes
150	150		- OOP implementation is not portable due to compiler dependent implementation (except for Objective C). Even worse, objects might not be compatible between different versions of the same compiler (i.e. TObject for FPC 2.4.x is not compatible to TObject for 2.6.x)
151	151
152	152		More specific information about which types can be exported:
153	153
154	154		- var / const / out parameters
155	155		- var - a variable is always passed by reference
156	156		- const - might be passed as reference (depending on the size of the variable and target CPU platform (ABI))
157	157		- out - a variable is always passed by reference
158	158		- if a parameter is passed by reference, it's typically a pointer reference in C
159	159		- Records - yes, they are compatible with most of the languages. Do keep in mind the "packing" of the record. The best approach is to use "packed record" (the data will be allocated in the most compact way).
160	160		- ShortStrings (fixed size strings) - yes - as a simple array of 256-characters (bytes), the first byte in the array is the number of characters
161	161		- Strings (dynamic strings: AnsiString) - incompatible - do not export; Consider using PChar instead (see example below)
162	162		- WideStrings (Windows ONLY - based on OLE) - could be used. Other languages would need to support OLEStrings as well (and handle them through Windows OLE utilities)
163	163		- WideStrings (non Windows), Unicode strings - incompatible - consider using PWideChar instead;
164	164		- Classes - incompatible. Consider using wrapper functions'
165	165		- Objects (old ones) - could be done, but you'll need to export all methods as separate functions/procedures
166	166		- Open Arrays - yes, but a single "open array" parameter is in fact 2 parameters - a pointer to the array and the size of the array (in elements). Example:
167	167
168		-	~~`// this declaration cannot be converted to C, as C doesn't have "open arrays"`\~~
169		-	~~`function Calculation(const params: array of TSomeData; a, b : integer): Integer;`~~
	168	+	``` pascal
	169	+	// this declaration cannot be converted to C, as C doesn't have "open arrays"
	170	+	function Calculation(const params: array of TSomeData; a, b : integer): Integer;
	171	+	```
170	172
171	173		could be called as
172	174
173		-	~~`// this declaration is easily converted to C`\~~
174		-	~~`function _Calculation(params: PSomeData; paramscount: Integer; a, b : integer): Integer;`~~
	175	+	``` pascal
	176	+	// this declaration is easily converted to C
	177	+	function _Calculation(params: PSomeData; paramscount: Integer; a, b : integer): Integer;
	178	+	```
175	179
176	180		- StaticArrays - yes - const might, if var will, be passed as a reference, rather than an array itslef;
177	181		- DynamicArrays - dynamic arrays are different from open arrays parameter - not portable. consider using arrays or create wrappers;
178	182		- Interfaces COM/CORBA - yes.
179	183		- Procedure types - yes - but keep in mind the calling convention, since a callback function call would need to use it as well.
180	184
181	185		### Returning string results as PChars
182	186
183	187		This example illustrates the use of PChar to return string-type results:
184	188
185	189		``` pascal
186	190		function InLibStringFunction: PChar; cdecl;
187	191		const
188	192		MyString: AnsiString = 'Hello World';
189	193		begin
190	194		result := PChar(MyString);
191	195		end;
192	196		```
193	197
194	198		The DLL's memory manager will allocate memory for the PChar. This means that your application must not free that memory. It needs to be freed by the DLL. This is not a problem if "MyString" does not change through the complete lifetime of your application.
195	199
196	200		If you want your application to be able to free the PChars then you can allow your main application to free the memory via the library.
197	201
198	202		So in that case use this kind of function:
199	203
200	204		``` pascal
201	205		function InLibStringFunction: PChar; cdecl;
202	206		const
203	207		MyString: AnsiString = 'Hello World';
204	208		begin
205	209		Result := GetMem(Length(MyString) + 1);
206	210		Move(@MyString[1], Result, Length(MyString));
207	211		Result[Length(MyString)] := 0;
208	212		end;
209	213		```
210	214
211	215		And, for freeing the allocated memory, you may add this procedure in the library, which you can then call from your main application :
212	216
213	217		``` pascal
214	218		procedure InLibFreeString(aStr: PChar);
215	219		begin
216	220		FreeMem(aStr);
217	221		end;
218	222		```
219	223
220	224		It is a good idea to store the pointer values of the allocated PChar results (e.g. TList or specialize TFPGList\<PChar\>) so that you can use this inside your exported FreeString function to check whether this is indeed a pointer that you need to free.
221	225
222	226		### Exposing objects using a wrapper
223	227
224	228		If you need to expose an object, you will need to create wrapper functions. These wrapper functions would accept a pointer parameter, cast it to the object and call the method. Sanity checks are advised.
225	229
226	230		This is also known as "flattening" the object (to a procedural API/interface).
227	231
228	232		Keep in mind that you will need to wrap/flatten:
229	233
230	234		- object methods
231	235		- object properties
232	236		- object fields (Note: BigChimp: what is an object field? Do you mean property?)
233	237
234	238		``` pascal
235	239		library libtest;
236	240
237	241		uses
238	242		Classes, ctypes, Math, SysUtils;
239	243
240	244		type
241	245		TMyClass = class(TThread)
242	246		public
243	247		enabled1: boolean;
244	248		int1, int2: shortint;
245	249		function function1(): integer; cdecl;
246	250		end;
247	251
248	252		function TMyClass.function1(): integer; cdecl;
249	253		begin
250	254		if enabled1 then
251	255		result := int1 + int2 else result := -1;
252	256		end;
253	257
254	258		exports
255	259		TMyClass.function1();
256	260		end.
257	261		```
258	262
259	263		Chould be "wrapped" like this:
260	264
261	265		``` pascal
262	266		library libtest;
263	267
264	268		uses
265	269		Classes, ctypes, Math, SysUtils;
266	270
267	271		type
268	272		TMyClass = class(TThread)
269	273		public
270	274		enabled1: boolean;
271	275		int1, int2: shortint;
272	276		function function1(): integer; cdecl;
273	277		end;
274	278
275	279		function TMyClass.function1(): integer; cdecl;
276	280		begin
277	281		if enabled1 then
278	282		result := int1 + int2
279	283		else
280	284		result := -1;
281	285		end;
282	286
283	287		function MyClassCreate:Pointer; cdecl;
284	288		begin
285	289		Result:=TMyClass.Create;
286	290		end;
287	291
288	292		function MyClassFree(obj:Pointer); cdecl;
289	293		begin
290	294		TMyClass(Obj).free;
291	295		end;
292	296
293	297		function MyClassSetEnabled(obj:Pointer; aenabled: Boolean); cdecl;
294	298		begin
295	299		TMyClass(Obj).enabled:=aenabled;
296	300		end;
297	301
298	302		function MyClassGetEnabled(obj:Pointer): Boolean; cdecl;
299	303		begin
300	304		Result:=TMyClass(Obj).enabled;
301	305		end;
302	306
303	307		function MyClassSetData(obj:Pointer; i1, i2: shortint); cdecl;
304	308		begin
305	309		TMyClass(Obj).int1:=i1;
306	310		TMyClass(Obj).int2:=i2;
307	311		end;
308	312
309	313		function MyClassGetData(obj:Pointer; var i1, i2: shortint); cdecl;
310	314		begin
311	315		i1:=TMyClass(Obj).int1;
312	316		i2:=TMyClass(Obj).int2;
313	317		end;
314	318
315	319		function MyClassFunction1(obj:Pointer): Integer; cdecl;
316	320		begin
317	321		Result:=TMyClass(Obj).function1
318	322		end;
319	323
320	324		exports
321	325		TMyClassCreate, MyClassFree, MyClassSetEnabled, MyClassGetEnabled
322	326		,MyClassSetData, MyClassGetData, MyClassFunction1;
323	327		end.
324	328		```
325	329
326	330		By the way, the same "wrapper"/flattening approach is taken when a C++ library (with classes) needs to be accessed from FPC (or any other language)
327	331
328	332		### .NET
329	333
330	334		More information [[Using Pascal Libraries with .NET and Mono\|here]]
331	335
332	336		### Java
333	337
334	338		More information [[Using Pascal Libraries with Java]]
335	339
336	340		## 같이보기
337	341
338	342		- [[Lazarus/FPC Libraries]]
339	343
340	344		## 참조
341	345
342	346		- FPC programmer's guide, chapter 12: FPC documentation on programming shared libraries
343	347		- <http://www.iecc.com/linker/>
344	348		- <ftp://ftp.freepascal.org/pub/fpc/docs-pdf/CinFreePascal.pdf>
345	349
346	350		---
347	351		From the Free Pascal wiki, page "shared library/ko", as it stood on 2020-02-26 after a change by Trev, out of the wiki's dump of 2024-05-26. Copyright stays with the author who wrote it, according to the old wiki's [[Licensing]] page. If you have concerns about this material, [message the admin](/wiki-contact).

Back to history