1WINEBUILD(1)                Wine Developers Manual                WINEBUILD(1)
2
3
4

NAME

6       winebuild - Wine dll builder
7

SYNOPSIS

9       winebuild [options] [inputfile...]
10

DESCRIPTION

12       winebuild  generates  the  assembly files that are necessary to build a
13       Wine dll, which is basically a Win32 dll encapsulated inside a Unix li‐
14       brary.
15
16       winebuild  has  different  modes,  depending on what kind of file it is
17       asked to generate. The mode is specified by one  of  the  mode  options
18       specified below. In addition to the mode option, various other command-
19       line option can be specified, as described in the OPTIONS section.
20

MODE OPTIONS

22       You have to specify exactly one of the following options, depending  on
23       what you want winebuild to generate.
24
25       --dll  Build  an  assembly file from a .spec file (see SPEC FILE SYNTAX
26              for  details),  or  from  a  standard  Windows  .def  file.  The
27              .spec/.def  file  is  specified via the -E option. The resulting
28              file must be assembled and linked to the other object  files  to
29              build  a working Wine dll.  In this mode, the input files should
30              be the list of all object files that will be linked into the fi‐
31              nal  dll,  to  allow  winebuild to get the list of all undefined
32              symbols that need to be imported from other dlls.
33
34       --exe  Build an assembly file for an executable. This is basically  the
35              same  as  the  --dll  mode  except  that  it  doesn't  require a
36              .spec/.def file as input, since an executable  need  not  export
37              functions. Some executables however do export functions, and for
38              those a .spec/.def file can be specified via the -E option.  The
39              executable is named from the .spec/.def file name if present, or
40              explicitly through the -F option. The resulting file must be as‐
41              sembled  and linked to the other object files to build a working
42              Wine executable, and all the other object files must  be  listed
43              as input files.
44
45       --def  Build  a .def file from a spec file. The .spec file is specified
46              via the -E option. This is used when building  dlls  with  a  PE
47              (Win32) compiler.
48
49       --implib
50              Build  a  .a  import library from a spec file. The .spec file is
51              specified via the -E option. If the output library name ends  in
52              .delay.a, a delayed import library is built.
53
54       --staticlib
55              Build a .a static library from object files.
56
57       --resources
58              Generate  a  .o file containing all the input resources. This is
59              useful when building with a PE compiler, since the  PE  binutils
60              cannot  handle  multiple resource files as input. For a standard
61              Unix build, the resource files are automatically  included  when
62              building  the  spec file, so there's no need for an intermediate
63              .o file.
64
65       --builtin
66              Mark a PE module as a Wine builtin module, by adding  the  "Wine
67              builtin DLL" signature string after the DOS header.
68
69       --fixup-ctors
70              Fixup constructors after a module has been built. This should be
71              done on the final .so module if its code contains  constructors,
72              to ensure that Wine has a chance to initialize the module before
73              the constructors are executed.
74

OPTIONS

76       --as-cmd=as-command
77              Specify the command to use to compile assembly  files;  the  de‐
78              fault is as.
79
80       -b, --target=cpu-manufacturer[-kernel]-os
81              Specify  the target CPU and platform on which the generated code
82              will be built. The target specification is in the standard auto‐
83              conf format as returned by config.sub.
84
85       -B directory
86              Add  the  directory  to the search path for the various binutils
87              tools like as, nm and ld.
88
89       --cc-cmd=cc-command
90              Specify the C compiler to use to compile assembly files; the de‐
91              fault is to instead use the assembler specified with --as-cmd.
92
93       -d, --delay-lib=name
94              Set  the  delayed  import  mode for the specified library, which
95              must be one of the libraries imported with the  -l  option.  De‐
96              layed  mode means that the library won't be loaded until a func‐
97              tion imported from it is actually called.
98
99       -D symbol
100              Ignored for compatibility with the C compiler.
101
102       -e, --entry=function
103              Specify the module entry point function; if not  specified,  the
104              default  is  DllMain  for dlls, and main for executables (if the
105              standard C main is not defined, WinMain is used  instead).  This
106              is only valid for Win32 modules.
107
108       -E, --export=filename
109              Specify  a  .spec  file (see SPEC FILE SYNTAX for details), or a
110              standard Windows .def file that defines the exports of  the  DLL
111              or executable that is being built.
112
113       --external-symbols
114              Allow  linking  to external symbols directly from the spec file.
115              Normally symbols exported by a dll have to be defined in the dll
116              itself;  this option makes it possible to use symbols defined in
117              another Unix library (for symbols defined in another dll, a for‐
118              ward specification must be used instead).
119
120       -f option
121              Specify  a  code  generation option. Currently -fPIC and -fasyn‐
122              chronous-unwind-tables are supported. Other options are  ignored
123              for compatibility with the C compiler.
124
125       --fake-module
126              Create  a fake PE module for a dll or exe, instead of the normal
127              assembly or object file. The PE module  contains  the  resources
128              for the module, but no executable code.
129
130       -F, --filename=filename
131              Set  the file name of the module. The default is to use the base
132              name of the spec file (without any extension).
133
134       -h, --help
135              Display a usage message and exit.
136
137       -H, --heap=size
138              Specify the size of the module local heap in bytes  (only  valid
139              for Win16 modules); default is no local heap.
140
141       -I directory
142              Ignored for compatibility with the C compiler.
143
144       -k, --kill-at
145              Remove the stdcall decorations from the symbol names in the gen‐
146              erated .def file. Only meaningful in --def mode.
147
148       -K flags
149              Ignored for compatibility with the C compiler.
150
151       --large-address-aware
152              Set a flag in the executable to notify the loader that this  ap‐
153              plication supports address spaces larger than 2 gigabytes.
154
155       --ld-cmd=ld-command
156              Specify the command to use to link the object files; the default
157              is ld.
158
159       -L, --library-path=directory
160              Append the specified directory to the list of  directories  that
161              are searched for import libraries.
162
163       -l, --library=name
164              Import  the  specified library, looking for a corresponding lib‐
165              name.def file in the directories specified with the -L option.
166
167       -m16, -m32, -m64
168              Generate respectively 16-bit, 32-bit or 64-bit code.
169
170       -marm, -mthumb, -march=option, -mcpu=option, -mfpu=option, -mfloat-
171       abi=option
172              Set code generation options for the assembler.
173
174       -mno-cygwin
175              Build  a  library  that  uses the Windows runtime instead of the
176              Unix C library.
177
178       -munix Build the Unix counterpart of a builtin module.
179
180       -M, --main-module=module
181              When building a 16-bit dll, set the name of its 32-bit  counter‐
182              part  to module. This is used to enforce that the load order for
183              the 16-bit dll matches that of the 32-bit one.
184
185       -N, --dll-name=dllname
186              Set the internal name of the module. It is only  used  in  Win16
187              modules.  The  default  is to use the base name of the spec file
188              (without any extension). This is used for KERNEL, since it lives
189              in KRNL386.EXE. It shouldn't be needed otherwise.
190
191       --nm-cmd=nm-command
192              Specify the command to use to get the list of undefined symbols;
193              the default is nm.
194
195       --nxcompat=yes|no
196              Specify whether the module is compatible with  no-exec  support.
197              The default is yes.
198
199       -o, --output=file
200              Set the name of the output file (default is standard output). If
201              the output file name ends in .o, the text output is  sent  to  a
202              temporary  file  that is then assembled to produce the specified
203              .o file.
204
205       --prefer-native
206              Specify that the native DLL should be preferred if available  at
207              run  time.  This can be used on modules that are mostly unimple‐
208              mented.
209
210       -r, --res=rsrc.res
211              Load resources from the  specified  binary  resource  file.  The
212              rsrc.res  file  can be produced from a source resource file with
213              wrc(1) (or with a Windows resource compiler).
214              This option is only necessary  for  Win16  resource  files,  the
215              Win32  ones  can simply listed as input files and will automati‐
216              cally be handled correctly (though the -r option will also  work
217              for Win32 files).
218
219       --safeseh
220              Mark object files as SEH compatible.
221
222       --save-temps
223              Do  not delete the various temporary files that winebuild gener‐
224              ates.
225
226       --subsystem=subsystem[:major[.minor]]
227              Set the subsystem of the executable, which can  be  one  of  the
228              following:
229              console for a command line executable,
230              windows for a graphical executable,
231              native for a native-mode dll,
232              wince for a ce dll.
233              The  entry point of a command line executable is a normal C main
234              function. A wmain function can be used instead if you  need  the
235              argument  array  to  use Unicode strings. A graphical executable
236              has a WinMain entry point.
237              Optionally a major and minor subsystem version can also be spec‐
238              ified; the default subsystem version is 4.0.
239
240       --syscall-table=id
241              Set the system call table id, between 0 and 3. The default is 0,
242              the ntdll syscall table. Only  useful  in  modules  that  define
243              syscall entry points.
244
245       -u, --undefined=symbol
246              Add  symbol  to  the list of undefined symbols when invoking the
247              linker. This makes it possible to force a specific module  of  a
248              static library to be included when resolving imports.
249
250       -v, --verbose
251              Display the various subcommands being invoked by winebuild.
252
253       --version
254              Display the program version and exit.
255
256       -w, --warnings
257              Turn on warnings.
258

SPEC FILE SYNTAX

260   General syntax
261       A  spec file should contain a list of ordinal declarations. The general
262       syntax is the following:
263
264       ordinal functype [flags] exportname ( [args...] ) [handler]
265       ordinal variable [flags] exportname ( [data...] )
266       ordinal extern [flags] exportname [symbolname]
267       ordinal stub [flags] exportname [ (args...) ]
268       ordinal equate [flags] exportname data
269       # comments
270
271       Declarations must fit on a single line, except if the end  of  line  is
272       escaped using a backslash character. The # character anywhere in a line
273       causes the rest of the line to be ignored as a comment.
274
275       ordinal specifies the ordinal number corresponding to the entry  point,
276       or '@' for automatic ordinal allocation (Win32 only).
277
278       flags  is  a series of optional flags, preceded by a '-' character. The
279       supported flags are:
280
281              -norelay
282                     The entry point  is  not  displayed  in  relay  debugging
283                     traces (Win32 only).
284
285              -noname
286                     The entry point will be exported by ordinal instead of by
287                     name. The name is still available for importing.
288
289              -ret16 The function returns a 16-bit value (Win16 only).
290
291              -ret64 The function returns a 64-bit value (Win32 only).
292
293              -register
294                     The function uses CPU register to pass arguments.
295
296              -private
297                     The function cannot be imported from other dlls,  it  can
298                     only be accessed through GetProcAddress.
299
300              -ordinal
301                     The entry point will be imported by ordinal instead of by
302                     name. The name is still exported.
303
304              -thiscall
305                     The function uses the thiscall calling convention  (first
306                     parameter in %ecx register on i386).
307
308              -fastcall
309                     The  function uses the fastcall calling convention (first
310                     two parameters in %ecx/%edx registers on i386).
311
312              -syscall
313                     The function is an NT system call. A  system  call  thunk
314                     will be generated, and the actual function will be called
315                     by the __wine_syscall_dispatcher function  that  will  be
316                     generated on the Unix library side.
317
318              -import
319                     The function is imported from another module. This can be
320                     used instead of a forward specification when an  applica‐
321                     tion expects to find the function's implementation inside
322                     the dll.
323
324              -arch=[!]cpu[,cpu]
325                     The entry point is only available on  the  specified  CPU
326                     architecture(s).  The  names  win32  and  win64 match all
327                     32-bit  or  64-bit  CPU  architectures  respectively.  In
328                     16-bit  dlls,  specifying  -arch=win32  causes  the entry
329                     point to be exported from the 32-bit  wrapper  module.  A
330                     CPU name can be prefixed with ! to exclude only that spe‐
331                     cific architecture.
332
333   Function ordinals
334       Syntax:
335       ordinal functype [flags] exportname ( [args...] ) [handler]
336
337       This declaration defines a function entry point.  The prototype defined
338       by  exportname ( [args...] )  specifies  the name available for dynamic
339       linking and the format of the arguments. '@' can be used instead of ex‐
340       portname for ordinal-only exports.
341
342       functype should be one of:
343
344              stdcall
345                     for a normal Win32 function
346
347              pascal for a normal Win16 function
348
349              cdecl  for a Win16 or Win32 function using the C calling conven‐
350                     tion
351
352              varargs
353                     for a Win16 or Win32 function using the C calling conven‐
354                     tion with a variable number of arguments
355
356       args should be one or several of:
357
358              word   (16-bit unsigned value)
359
360              s_word (16-bit signed word)
361
362              long   (pointer-sized integer value)
363
364              int64  (64-bit integer value)
365
366              int128 (128-bit integer value)
367
368              float  (32-bit floating point value)
369
370              double (64-bit floating point value)
371
372              ptr    (linear pointer)
373
374              str    (linear pointer to a null-terminated ASCII string)
375
376              wstr   (linear pointer to a null-terminated Unicode string)
377
378              segptr (segmented pointer)
379
380              segstr (segmented pointer to a null-terminated ASCII string).
381
382              Note:  The 16-bit and segmented pointer types are only valid for
383                     Win16 functions.
384
385       handler is the name of the actual C function that will  implement  that
386       entry  point  in 32-bit mode. The handler can also be specified as dll‐
387       name.function to define a forwarded function (one whose  implementation
388       is  in  another  dll). If handler is not specified, it is assumed to be
389       identical to exportname.
390
391       This first example defines an entry point  for  the  32-bit  GetFocus()
392       call:
393
394              @ stdcall GetFocus() GetFocus
395
396       This  second  example  defines an entry point for the 16-bit CreateWin‐
397       dow() call (the ordinal 100 is just an example); it also shows how long
398       lines can be split using a backslash:
399
400              100 pascal CreateWindow(ptr ptr long s_word s_word s_word \
401                  s_word word word word ptr) WIN_CreateWindow
402
403       To declare a function using a variable number of arguments, specify the
404       function as varargs and declare it in the C file with a '...' parameter
405       for  a  Win32 function, or with an extra VA_LIST16 argument for a Win16
406       function.  See the wsprintf* functions in user.exe.spec and user32.spec
407       for an example.
408
409   Variable ordinals
410       Syntax:
411       ordinal variable [flags] exportname ( [data...] )
412
413       This  declaration  defines  data storage as 32-bit words at the ordinal
414       specified.  exportname will be the name available for dynamic  linking.
415       data  can  be  a  decimal number or a hex number preceded by "0x".  The
416       following example defines the variable VariableA at ordinal 2 and  con‐
417       taining 4 ints:
418
419              2 variable VariableA(-1 0xff 0 0)
420
421       This  declaration  only  works in Win16 spec files. In Win32 you should
422       use extern instead (see below).
423
424   Extern ordinals
425       Syntax:
426       ordinal extern [flags] exportname [symbolname]
427
428       This declaration defines an entry that simply maps to a C symbol (vari‐
429       able  or function). It only works in Win32 spec files.  exportname will
430       point to the symbol symbolname that must be defined in the C code.  Al‐
431       ternatively,  it can be of the form dllname.symbolname to define a for‐
432       warded symbol (one whose implementation is in another dll). If  symbol‐
433       name is not specified, it is assumed to be identical to exportname.
434
435   Stub ordinals
436       Syntax:
437       ordinal stub [flags] exportname [ (args...) ]
438
439       This declaration defines a stub function. It makes the name and ordinal
440       available for dynamic linking, but will terminate execution with an er‐
441       ror message if the function is ever called.
442
443   Equate ordinals
444       Syntax:
445       ordinal equate [flags] exportname data
446
447       This  declaration  defines an ordinal as an absolute value.  exportname
448       will be the name available for dynamic linking.  data can be a  decimal
449       number or a hex number preceded by "0x".
450

AUTHORS

452       winebuild  has  been  worked on by many people over the years. The main
453       authors are Robert J. Amstadt, Alexandre Julliard, Martin  von  Loewis,
454       Ulrich  Weigand  and Eric Youngdale. Many other people have contributed
455       new features and bug fixes. For a complete list,  see  the  git  commit
456       logs.
457

BUGS

459       It  is  not yet possible to use a PE-format dll in an import specifica‐
460       tion; only Wine dlls can be imported.
461
462       Bugs can be reported on the Wine bug tracker https://bugs.winehq.org⟩.
463

AVAILABILITY

465       winebuild is part of the Wine distribution, which is available  through
466       WineHQ, the Wine development headquarters https://www.winehq.org/⟩.
467

SEE ALSO

469       wine(1), winegcc(1), wrc(1),
470       Wine documentation and support https://www.winehq.org/help⟩.
471
472
473
474Wine 6.21                        October 2005                     WINEBUILD(1)
Impressum