[postgis-tickets] [PostGIS] #3167: Windows build broken, lwin_geojson.c undefined reference to json_..

[PostGIS]

#3167: Windows build broken, lwin_geojson.c undefined reference to json_..
----------------------+---------------------------
  Reporter:  robe     |      Owner:  strk
      Type:  defect   |     Status:  closed
  Priority:  blocker  |  Milestone:  PostGIS 2.2.0
 Component:  postgis  |    Version:  trunk
Resolution:  fixed    |   Keywords:
----------------------+---------------------------

Comment (by esseffe):

 just few clarifications about MinGW, -no-undefined and related

 step #1: why is required declaring -no-undefined
 ----------------------------------------------------------
 every canonical build system producing some library should be always
 expected to create and install both the static and the dynamic versions of
 the library.


 this is usually true on any standard Linux, where the canonical
 ./configure script will always create both the static (*.a) and the
 dynamic (*.so) libraries (unless you pass an explicit --disable-static or
 --disable-shared option) and following this approach users will be
 absolutely free to link the one or the other accordingly to their specific
 requirements.


 on Windows there is a subtle difference: there are no *.so shared
 libraries, here we have *.dll dynamic libraries which are based on a
 completely different architecture.
 MinGW/MSYS still continues to be able to generate both static and dynamic
 libraries even on Windows, but due to technical limitations imposed by the
 intrinsic DLL design a further -no-undefined option is expected to be
 explicitly passed to libtool.


 if -no-undefined isn't specified you'll simply get the static *.a library
 and no DLL at all will be created.


 practically all FLOSS libraries I'm aware of usually define someway -no-
 undefined so to nicely create both the static and the dynamic libraries
 even when using MinGW on Windows.
 the unique remarkable exception I know to this standard rule is
 represented by libgeotiff (and liblwgeom, of course).
 in this case manually patching the corresponding Makefile,in is always
 required before running ./configure: this hack effectively works, but it
 surely is rather inelegant.



 step #2: static vs dynamic linkage
 ----------------------------------------------------------
 assuming that in the previous steps we've effectively built
 and installed both the static and the dynamic versions of the
 same library (let say libxyz), it's now time to link libxyz
 to some other library or may be to some application.

 gcc (and MinGW) allows us to freely choose between static and
 dynamic linkage as we wish better, but there are few critical
 details requiring careful consideration.

 when a fine control about the linkage mode is absolutely required
 the best approach is the one to always explicitly select the
 required library object thus completely by-passing any possible
 interference from the build tools.

 this will certainly statically link libxyz

 gcc abcd.c -o abdd.exe /usr/local/lib/libxyz.a


 this will surely dynamically link libxyz

 gcc abcd.c -o abcd.c /usr/local/lib/libxyz.dll.a

 and this too will dynamically link libxyz

 gcc abcd.c -o abcd.c /usr/local/bin/libxyz-0.dll


 finally, a last case exists, and it's rather ambiguous

 gcc abcd.c -o abcd.exe -lxyz

 in this specific case we are substantially leaving gcc
 absolutely free to choose its preferred version of
 libxyz; and if a possibility exists gcc will always
 opt for dynamic linkage, because this one is the
 standard assumption on any Linux.
 Just in only one case we can get a statically linked
 executable following this approach: if only a single
 version of the library exists, and it actually is
 the static member.

 please notice:
 gcc -static abcd.c -o abcd.exe -lxyz

 this will surely create a statically linked executable,
 because the -static flag now informs gcc about your
 preferences.

 I easily guess that the link problems reported by
 Regina after (correctly) introducing the -no-undefined
 option can be easily tracked back to some incomplete
 linker directive hopefully relying on the incorrect
 assumption that only the static library should exists.

 my 5 cents, Sandro

--
Ticket URL: <https://trac.osgeo.org/postgis/ticket/3167#comment:10>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.