gcc links to libcmain when generating a dll

[skidmarks]

 > On 2025-05-22 12:37, Arthur Schwarz via Cygwin wrote:
 > > I can't figure this one out.
 > >
 > >  > clear;g++ -flinker-output=dyn -o slip.dll *.o
 > >
 > > generates:
 > >
 > > 
/usr/lib/gcc/x86_64-pc-cygwin/12/../../../../x86_64-pc-cygwin/bin/ld: 
/usr/lib/
 > > gcc/x86_64-pc-cygwin/12/../../../../lib/libcygwin.a(libcmain.o): in 
function
 > > `main':
 > > /usr/src/debug/cygwin-3.6.1-1/winsup/cygwin/lib/libcmain.c:37:
 > > (.text.startup+0x79): undefined reference to `WinMain'
 > > collect2: error: ld returned 1 exit status
 > >
 > > But I am developing a dll, not a windows application. The gcc.pdf 
manual says:
 > >
 > >     -flinker-output=type
 > >     This option controls code generation of the link-time optimizer. By
 > >     default the
 > >     linker output is automatically determined by the linker plugin. For
 > >     debugging
 > >     the compiler and if incremental linking with a non-LTO object file
 > >     is desired,
 > >     it may be useful to control the type manually.
 > >
 > >     If type is ‘dyn’, code generation produces a shared library. In 
this
 > >     case ‘-fpic’
 > >     or ‘-fPIC’ is preserved, but not enabled automatically. This allows
 > >     to build
 > >     shared libraries without position-independent code on architectures
 > >     where this
 > >     is possible, i.e. on x86.
 > >
 > > My code is not executable and nowhere links to or uses any Windows 
code. It does
 > > not have a WinMain method and there is no link to libcmain.o in the 
object
 > > folder (*.o does not have libcmain.o).
 > >
 > > How do I get rid of this link error?

 > On 2025-05-22 19:19:46 Brian Inglis via Cygwin wrote:
 >
 > Tell the linker (ld/gcc/g++) not the LTO code generator!
 > If your "code" is not executable (data?) then LTO is irrelevant.
 >
 > Please note:
 >
 > $ info gcc flinker-output | tail -8
 > ---------- Footnotes ----------
 >
 > (1) On some systems, ‘gcc -shared’ needs to build supplementary stub
 > code for constructors to work.
 > On multi-libbed systems, ‘gcc -shared’ must select the correct 
support libraries
 > to link against.
 > *Failing to supply the correct flags may lead to subtle defects.*
 > Supplying them in cases where they are not necessary is innocuous.
 >
 > A couple of examples from cygport scripts:
 >
 > $ grep -iA3 'CC.*-shared' **/*.cygport
 > expect.cygport:    cygmake SHLIB_LD='$(CC) -shared -Wl,--out-implib,$@.a'
 > --
 > libvpx.cygport:    $CC -shared -fpic -o cygvpx-$ABI.dll            \
 > libvpx.cygport-        -Wl,--out-implib,libvpx.dll.a \
 > libvpx.cygport- -Wl,--whole-archive,libvpx.a,--no-whole-archive    \
 > libvpx.cygport-        -Wl,--version-script,$EXPORT_FILE
 >
 > Your program will need to link with the implib.
 >
 > --
 > Take care. Thanks, Brian Inglis              Calgary, Alberta, Canada
 >
 > La perfection est atteinte                   Perfection is achieved
 > non pas lorsqu'il n'y a plus rien à ajouter  not when there is no 
more to add
 > mais lorsqu'il n'y a plus rien à retrancher  but when there is no 
more to cut
 >                                  -- Antoine de Saint-Exupéry

Thanks!

 > g++ -shared -flinker-output=dyn -o slip.dll *.o

ran with not errors.

Is there any documentation available on cygwin specific issues? This 
seems like
a question that I should be able to answer on my own. One residual 
question that
a cygwin specific manual may answer is why libcmain.a was included at all.

art