[Xapian-tickets] [Xapian] #832: Compiling xapian with meson. Strange error in tests.

[Xapian]

#832: Compiling xapian with meson. Strange error in tests.
--------------------------+-------------------------------
 Reporter:  mgautier      |             Owner:  Olly Betts
     Type:  task          |            Status:  new
 Priority:  normal        |         Milestone:
Component:  Build system  |           Version:
 Severity:  normal        |        Resolution:
 Keywords:                |        Blocked By:
 Blocking:                |  Operating System:  All
--------------------------+-------------------------------
Comment (by mgautier):

 > > It struck me that this is rather suspicious - there shouldn't be any
 undefined references (and there aren't with the current build system) so
 this suggests to me that you aren't putting the correct set of files into
 the library (or you're misbuilding them in some way that means symbols are
 missing, perhaps due to symbol visibility).
 >
 > Thanks, I will search on this direction

 Well, it seems I was wrong with undefined references (and I would prefer
 being right as it doesn't seems simpler).

 Dll need us to mark public (export) symbol with `__declspec(dllexport)`
 but you never seems to do it. You have the `XAPIAN_VISIBILITY_DEFAULT`
 defined in `visibility.h` but it is only used for gcc whit symbol
 visibility support.
 With autotools on windows it seems that libtool does the job for us in
 `m4/libtool.m4` around line 4010. It seems to create a def file we can
 pass to compiler and avoid the `__declspec`.

 But meson doesn't do it for us. Strangely, I had the same issue on libzim
 and open a issue on meson at the time :
 https://github.com/mesonbuild/meson/issues/7838

 Anyway, I have patched `visibility.h` to define
 `XAPIAN_VISIBILITY_DEFAULT` to `__deplcspec(dllexport)` on msvc. But new
 problems coming. I have a lot of warning because (private) data member
 classes are not exported (which seems to be only a warning and we can
 ignore it https://stackoverflow.com/questions/2132747/warning-c4251-when-
 building-a-dll-that-exports-a-class-containing-an-
 atlcstrin#comment66255284_4563701)

 But the real problem is that cl complains that intrusive_ptr
 (`~intrusive_ptr`) uses undefined type `Xapian::Compactor::Internal`. This
 is strange as we actually use `~intrusive_ptr` in `Xapian::~Compactor`  in
 `compactor.cc` when `Internal` is actually defined, so it should be ok (at
 least it is with gcc).

 But cl complain as we use `~intrusive_ptr` in `compactor.h` line 185. I
 suspect some strange rule about symbol definition in dll but I haven't
 found documentation confirming this.
 I don't know why it is ok with libtool build. Maybe using a `.def` file do
 not trigger the same things.

 Anyway, using delete on incomplete type is UB
 (https://en.cppreference.com/w/cpp/language/delete) so I hope the
 windows&libtool version correctly call destructor from `compactor.cc` and
 not silently generate UB.


 ---

 Sorry if I spam you. I think I will use this issue to share my progress.
 Hope it is ok for you, I will find somewhere else if not.
-- 
Ticket URL: <https://trac.xapian.org/ticket/832#comment:5>
Xapian <https://xapian.org/>
Xapian