Hi Rainer, Dr Rainer Woitok writes:
> Olaf, > > On Saturday, 2020-02-08 12:52:49 +0900, you wrote: > > [ "> >" refers to Bruce Schultz' mail ] > >> ... >> > That fails now for me with the same error you error you had. >> >> For me too (on our CI's debian-10-full setup with 336cbdfd as well as >> 1.0.29) but I also get a pile of multiple definitions for sanei_debug >> and sanei_usb functions when linking libdll_preload.a. > > I also saw these "multiple definition" warnings, but in my experience > compiling other people's programs almost ever produces some warnings, so > what the heck :-) That may be fine for you but when you report an issue it's nice to include this. Most folks on the list are not psychic and I didn't get a crystal ball from Santa Claus last year either ;-/ BTW, although they don't cover many build scenarios, our Debian CI builds are free of compiler warnings and we make an active effort to keep them that way via "All Warnings Are Really Errors" (AWARE). >> ... >> I don't know what is going on off the top of my head but suggest you >> follow Bruce's suggestion, at least for the time being, unless you >> really *need* the --disable-dynamic *and* --enable-preload options. > > I did, and yes, now the compilation succeedes. I'll tackle the original > problem with scanning using the ADF next and will report here what I'll > find out. OK. > Regarding all these options, well "./configure help" could probably not > be more nebulous: > > --enable-static[=PKGS] build static libraries [default=no] > --enable-shared[=PKGS] build shared libraries [default=yes] Those are courtesy of libtool, so you can blame its developers for that. > # So why not specify "--enable-shared"? > > ... > --disable-dynamic Disable dynamic loading of backends Dynamic loading and shared libraries are two different things. Shared libraries are automatically loaded at program startup. As a programmer you don't have to do anything to get that taken care of. For dynamic loading you actually have to write code that loads the library if your program decides it's needed. Our dll backend does dynamic loading and is the default libsane shared library. > # Since I'm only specifying a single backend anyway, why not include it > # right into the binary rather than load it at start-up? Why not make that backend your libsane instance? Then your SANE frontend will load that automatically at program start up if it's dynamically linked with the libsane shared library. # You'd cut the dll backend out of the picture this way. > ... > --disable-preload Disable preloading of backends To be honest, I'm not sure what this option achieves myself. > # As above: why not enable this option and thus include the single back- > # end right into the binary? > > But obviously my interpretation of these option descriptions was bogus. I hope the above clarified a bit but, when in doubt or not really knowing what you're doing, going with the defaults is often not a bad decision ;-) > By the way: I'm meanwhile also specifying "--disable-locking" to get rid > of this warning about allegedly missing group "uucp". Hope this helps, -- Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Software https://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join
