MantisBT - Doomseeker
View Issue Details
IDProjectCategoryView StatusDate SubmittedLast Update
0003232Doomseeker[All Projects] Bugpublic2017-09-01 10:402018-10-27 22:53
ReporterWubTheCaptain 
Assigned ToBlzut3 
PrioritylowSeveritymajorReproducibilityalways
StatusclosedResolutionfixed 
Platformx86_64OSDebian GNU/LinuxOS Versionbuster/sid
Product Version1.1 
Target Version1.2Fixed in Version1.2 
Summary0003232: Doomseeker installs architecture-dependent engine libraries to arch-independent directory (multi-arch support)
DescriptionDoomseeker installs and looks for engine libraries from architecture independent directory /usr/share/doomseeker/engines.

/usr/share is reserved for architecture-independent files in the Filesystem Hierarchy Standard. The engine libraries currently in /usr/share/doomseeker/engines are architecture dependent ELF binary objects and should be under /usr/lib structure instead.

Lintian tag: arch-dependent-file-in-usr-share (severity serious, certainty certain)
Steps To Reproduce

  • Compile Doomseeker from source, following instructions in the <code>COPYING</code> file. Build at least one of the supported engines (Zandronum, Chocolate Doom, Odamex, SRB2). (All engines are built by default.)

  • Install to a desired prefix (root path). Check /usr/share/doomseeker/engines in that root path.

  • Alternatively, remove or move engines directory from $HOME/.doomseeker/engines, current build directory and current relative directory. Then run Doomseeker from a terminal. Check the stdout for "Attempting to load plugins from directory" messages.

Additional Information'http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA [^]'

$ ./doomseeker
[13:08:43] Starting Doomseeker. Hello World! :)
...
[13:08:43] Attempting to load plugins from directory: /home/wub/.doomseeker/engines
[13:08:43] Attempting to load plugins from directory: /home/wub/.local/src/doomseeker/doomseeker-1.1/obj-x86_64-linux-gnu/engines

[13:08:43] Attempting to load plugins from directory: engines
[13:08:43] Attempting to load plugins from directory: /usr/share/doomseeker/engines
[13:08:43] Attempting to load plugins from directory: :/engines
...


(Reproducible on vanilla 1.1 sources, my DFSG build removes unused Windows binary objects which is what I now had. I removed ./obj-x86_64-linux-gnu/engines here.)

$ file /usr/share/doomseeker/engines/libzandronum.so
/usr/share/doomseeker/engines/libzandronum.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), 
dynamically linked, BuildID[sha1]=2b7532c81d8d2ec047a540aeae9d8cb6d7261237, stripped
TagsNo tags attached.
Relationships
related to 0003301closed  libwadseeker shared library dependency is not handled properly at runtime in Doomseeker after "sudo make install" 
child of 0003246acknowledged  Debian packaging 
Attached Files
Issue History
Date ModifiedUsernameFieldChange
2017-09-01 10:40WubTheCaptainNew Issue
2017-09-01 16:29ZalewaRelationship addedchild of 0003246
2017-09-06 02:30Blzut3Assigned To => Blzut3
2017-09-06 02:30Blzut3Statusnew => assigned
2017-09-06 02:31Blzut3Target Version => 1.2
2017-09-24 22:44Blzut3Note Added: 0018375
2017-09-24 22:44Blzut3Statusassigned => needs testing
2017-09-25 01:08WubTheCaptainNote Added: 0018376
2017-09-25 01:43Blzut3Note Added: 0018377
2017-09-25 01:43Blzut3Statusneeds testing => assigned
2017-09-25 13:13WubTheCaptainNote Added: 0018378
2017-09-25 13:25WubTheCaptainNote Added: 0018379
2017-09-25 13:40WubTheCaptainNote Added: 0018380
2017-10-08 23:32Blzut3Note Added: 0018487
2017-10-08 23:32Blzut3Statusassigned => needs review
2017-10-09 03:28WubTheCaptainAssigned ToBlzut3 => Zalewa
2017-10-09 03:28WubTheCaptainStatusneeds review => assigned
2017-10-09 03:28WubTheCaptainNote Added: 0018492
2017-10-09 03:28WubTheCaptainStatusassigned => needs review
2017-10-09 03:30WubTheCaptainNote Edited: 0018492bug_revision_view_page.php?bugnote_id=18492#r11092
2017-10-09 03:39WubTheCaptainNote Added: 0018493
2017-10-09 03:43WubTheCaptainNote Edited: 0018493bug_revision_view_page.php?bugnote_id=18493#r11094
2017-10-09 03:47WubTheCaptainNote Edited: 0018493bug_revision_view_page.php?bugnote_id=18493#r11095
2017-10-09 03:50WubTheCaptainAdditional Information Updatedbug_revision_view_page.php?rev_id=11097#r11097
2017-10-09 04:07WubTheCaptainNote Added: 0018494
2017-10-09 04:21WubTheCaptainSummaryDoomseeker installs architecture-dependent engine libraries to arch-independent directory => Doomseeker installs architecture-dependent engine libraries to arch-independent directory (multi-arch support)
2017-10-09 04:26WubTheCaptainAssigned ToZalewa => Blzut3
2017-10-09 04:26WubTheCaptainStatusneeds review => assigned
2017-10-09 04:31Blzut3Note Added: 0018495
2017-10-09 05:03WubTheCaptainNote Added: 0018496
2017-10-09 05:10WubTheCaptainNote Edited: 0018496bug_revision_view_page.php?bugnote_id=18496#r11101
2017-10-09 05:11Blzut3Note Added: 0018497
2017-10-09 05:13WubTheCaptainNote Edited: 0018496bug_revision_view_page.php?bugnote_id=18496#r11102
2017-10-09 05:28WubTheCaptainNote Added: 0018499
2017-10-09 05:29WubTheCaptainNote Edited: 0018499bug_revision_view_page.php?bugnote_id=18499#r11104
2017-10-09 05:58WubTheCaptainNote Added: 0018501
2017-10-09 05:58WubTheCaptainStatusassigned => needs review
2017-10-09 06:43WubTheCaptainNote Added: 0018502
2017-10-11 19:32ZalewaNote Added: 0018536
2017-10-12 05:48WubTheCaptainNote Added: 0018539
2017-10-12 05:53WubTheCaptainNote Edited: 0018539bug_revision_view_page.php?bugnote_id=18539#r11130
2017-10-12 05:54WubTheCaptainNote Edited: 0018539bug_revision_view_page.php?bugnote_id=18539#r11131
2017-10-12 05:59WubTheCaptainNote Added: 0018540
2017-10-12 06:14WubTheCaptainNote Added: 0018541
2017-10-12 06:15WubTheCaptainNote Edited: 0018541bug_revision_view_page.php?bugnote_id=18541#r11133
2017-10-12 06:16WubTheCaptainNote Edited: 0018541bug_revision_view_page.php?bugnote_id=18541#r11134
2017-10-12 06:23WubTheCaptainNote Added: 0018542
2017-10-12 06:45WubTheCaptainRelationship addedrelated to 0003301
2017-10-12 17:24ZalewaNote Added: 0018545
2017-10-12 17:26ZalewaNote Edited: 0018545bug_revision_view_page.php?bugnote_id=18545#r11138
2017-10-12 17:57WubTheCaptainNote Added: 0018546
2017-10-12 17:57WubTheCaptainStatusneeds review => assigned
2017-10-12 17:58WubTheCaptainNote Edited: 0018546bug_revision_view_page.php?bugnote_id=18546#r11140
2017-10-29 01:07Blzut3Note Added: 0018640
2017-10-29 01:07Blzut3Statusassigned => needs review
2017-10-29 18:10WubTheCaptainNote Added: 0018652
2017-10-29 18:12WubTheCaptainNote Edited: 0018652bug_revision_view_page.php?bugnote_id=18652#r11216
2017-10-29 18:38Blzut3Note Added: 0018654
2018-09-25 02:31WubTheCaptainNote Added: 0019743
2018-09-25 02:34WubTheCaptainNote Added: 0019744
2018-09-25 03:34Blzut3Statusneeds review => assigned
2018-10-08 05:31Blzut3Note Added: 0019999
2018-10-08 05:31Blzut3Statusassigned => needs testing
2018-10-08 09:59WubTheCaptainNote Added: 0020005
2018-10-08 09:59WubTheCaptainStatusneeds testing => resolved
2018-10-08 09:59WubTheCaptainResolutionopen => fixed
2018-10-08 10:01WubTheCaptainNote Added: 0020006
2018-10-13 19:05WubTheCaptainFixed in Version => 1.2
2018-10-27 22:53WubTheCaptainStatusresolved => closed

Notes
(0018375)
Blzut3   
2017-09-24 22:44   
'https://bitbucket.org/Doomseeker/doomseeker/commits/2499674facfe [^]'
(0018376)
WubTheCaptain   
2017-09-25 01:08   
src/core/datapaths.cpp: Lines 250 and 322 seem like a good idea at first, but no longer allow installing in /usr/{share,lib}/doomseeker and let the sysadmin make local changes to /usr/local/{share,lib}/doomseeker?

src/core/datapaths.cpp: Line 320 uses QCoreApplication::applicationDirPath() directly, while pluginSearchLocationPaths() calls workingDirectory(). Is that what you wanted?

src/core/datapaths.h: Typo "an oreder list" on line 226.

src/core/main.cpp: Line 336 comment is not related to this commit, but it's also possibly misleading.

I'll have to read how multiarch works for Debian, if any changes are required there. E.g. /usr/lib/x86_64-linux-gnu/doomseeker/*.so for x86_64 or /usr/lib/i368-linux-gnu/doomseeker/*.so for i386 to support multiarch. May be something the software doesn't need to care about.
(0018377)
Blzut3   
2017-09-25 01:43   
Is making changes in /usr/local to a program installed in /usr a real thing? I know GCC for example bakes its install path somewhere so it can't be easily moved. Behavior seems kind of oddly specific since it wouldn't really apply if not installed to /usr.

I could add an option for specifying a lib directory for multiarch support.

As for the workingDirectory thing, as the comments I've added to the header file says that has been a bit of a misnomer. In the early days there was a logical "cd" happening with it, but then we added "./" as search paths anyway while never renaming the variable. Renaming it now would break ABI. It is added to the plugin search directories since that's where they're expected to be on Windows. The actual working directory is added in the next line.
(0018378)
WubTheCaptain   
2017-09-25 13:13   
/usr/local is for local additions (sorry, not changes!) to a package, which should ensure to take precedence over the equivalents in /usr. Packages themselves must not install to /usr/local. This is said in Debian Policy Manual v4.1.0.0, section 9.1.2. Site-specific programs.

One may want to install Doomseeker and its bundled plugins to /usr, but add non-bundled or custom engine plugins not from the packaging system to /usr/local. I'm not sure how sensible it is to require installing Doomseeker to /usr/local to support this use case. It's a little bit difficult for me to interpret this.

Multiarch is somewhat dynamic and transparent to the program from /etc/ld.so.conf.d/* configuration, so the linker doesn't have to care where the files are placed.

At least with libvpx4 package (an example), the multiarch library placement is done at configuration time (autoconf) with configure_flags --target=generic-gnu and making a shell call to dpkg-architecture. That said, it's not a strict requirement to support this. An example from a CMake package would be mariadb-10.1, debian/rules:

cmake -DCMAKE_INSTALL_PREFIX=/usr \
$(CMAKEFLAGS) \
-DWITH_SSL=bundled \
-DCOMPILATION_COMMENT="$(DEB_VENDOR) $(RELEASE)" \
-DMYSQL_SERVER_SUFFIX="-$(DEB_VERSION_REVISION)" \
-DSYSTEM_TYPE="debian-$(DEB_HOST_GNU_SYSTEM)" \
-DCMAKE_SYSTEM_PROCESSOR=$(DEB_HOST_ARCH) \
-DBUILD_CONFIG=mysql_release \
-DINSTALL_LIBDIR=lib/$(DEB_HOST_MULTIARCH) \
-DINSTALL_PLUGINDIR=lib/$(DEB_HOST_MULTIARCH)/mariadb18/plugin \
-DINSTALL_MYSQLTESTDIR=share/mysql/mysql-test \
-DPLUGIN_AUTH_SOCKET=STATIC \
-DDEB=$(DEB_VENDOR) ..'


Notice especially -DCMAKE_SYSTEM_PROCESSOR, -DINSTALL_LIBDIR and -DINSTALL_PLUGINDIR options.
(0018379)
WubTheCaptain   
2017-09-25 13:25   
More info on multiarch there:


  • https://wiki.debian.org/Multiarch

  • https://wiki.debian.org/Multiarch/Implementation

  • https://wiki.ubuntu.com/MultiarchSpec



Even if the lib directory is not configurable, at least Debian's packaging allows to override the install directories.
(0018380)
WubTheCaptain   
2017-09-25 13:40   
There's also /opt in FHS for "add-on packages that contain static files", but it's rarely used and not available in OpenBSD at least.

CMake's module GNUInstallDirs also has CMAKE_INSTALL_LIBDIR among others, unlike the mariadb-10.1 example above.'https://cmake.org/cmake/help/latest/module/GNUInstallDirs.html [^]'
(0018487)
Blzut3   
2017-10-08 23:32   
Addressed the multiarch issue in:'https://bitbucket.org/Doomseeker/doomseeker/commits/2a58d7c832d9635ee4dea69baaa85f47ce4298cb [^]'

As for /usr/local, I'm going to have to mark that is out of scope for this ticket as that's a fairly nuanced suggestion. Right now Doomseeker only loads plugins from one directory and there's no elegant way for us to say "oh I got plugin X from an earlier directory therefore I should skip loading the one I found later." I don't know how symbol visibility plays into this, but I suspect that more needs to be done than load everything an unload/reject if the plugin matches something we loaded earlier. In any case this seems like a new feature not a packaging issue.
(0018492)
WubTheCaptain   
2017-10-09 03:28   
(edited on: 2017-10-09 03:30)
Zalewa, please review. I will test if later if the code is good.
(0018493)
WubTheCaptain   
2017-10-09 03:39   
(edited on: 2017-10-09 03:47)
Actually, I should also ask: Does Doomseeker even need to know about lib or multiarch paths in src/core/datapaths.cpp, because ldconfig cache knows about those anyway? If not so, could I not activate libc's "ldconfig" trigger to ensure the ldconfig cache is updated? Seems slightly reduntant, because lintian wants me to do this anyway during Debian packaging. Obviously this was not the case with /usr/share (previous behavior), where Doomseeker had to explicitly know of .so files installed there.

Multiarch support in the build system is a welcomed addition.
(0018494)
WubTheCaptain   
2017-10-09 04:07   
GNUInstallDirs may also require updating the cmake_minimum_required VERSION macro to 3.0.x.
(0018495)
Blzut3   
2017-10-09 04:31   
My build of CMake 2.8.12.2 has it. Have not verified if it produces the correct results, but 2.8.12 works fine for building.
(0018496)
WubTheCaptain   
2017-10-09 05:03   
(edited on: 2017-10-09 05:13)
Doomseeker fails to execute on Xubuntu 16.04.3 LTS LiveCD, after sudo make install as instructed in COMPILE.txt.

Its default install prefix is /usr/local, so libwadseeker.so gets installed there too and it can't find it. Odd.

-DCMAKE_INSTALL_PREFIX=/usr works fine.
(0018497)
Blzut3   
2017-10-09 05:11   
Guess CMake isn't as smart about the RPATH as I thought it was (does a pretty decent job at figuring out what it should be at build time though). I'm not sure this is the ticket for that issue, but I guess I should look into if there's a way we can determine if the install prefix is part of the default library search path or not.
(0018499)
WubTheCaptain   
2017-10-09 05:28   
(edited on: 2017-10-09 05:29)
True, that's a seperate issue.

I've tested the current behavior on a native arch x86_64 machine.


  • CMAKE_INSTALL_PREFIX at /usr/local (default with Xubuntu 16.04.3 LTS LiveCD) installed engines under /usr/local/lib/doomseeker/engines/ and libwadseeker to /usr/local/lib/libwadseeker.so.

  • CMAKE_INSTALL_PREFIX changed to /usr (-DCMAKE_INSTALL_PREFIX=/usr) installed engines under /usr/lib/x86_64-linux-gnu/doomseeker/engines and libwadseeker to /usr/lib/x86_64-linux-gnu/libwadseeker.so.



The distinction between /usr and /usr/local is correct. I've not tested cross-compiling yet for other architectures.
(0018501)
WubTheCaptain   
2017-10-09 05:58   
Here's my proposal to resolve this ticket as fixed:


  1. Fix the "oreder" typo introduced in commit 2499674facfe.

  2. Wait for Zalewa to comment on "Do we care about this on other platforms?"
     and/or remove the comment in code (commit 2a58d7c).

  3. Test a cross-compile to another architecture. (I don't know yet how to go about doing this with CMake.)

  4. Check if Doomseeker is now needlessly reinventing ldconfig cache functionality (related to previous, because /usr/local is not in /etc/ld.so.conf.d/*), or open another issue for this.

  5. Open another issue about RPATH or us not triggering libc's ldconfig.

  6. Mark this ticket as resolved.
(0018502)
WubTheCaptain   
2017-10-09 06:43   
Blzut3: Also note there's no sanity check for INSTALL_LIBDIR now in src/core/datapaths.cpp, while one was added for INSTALL_PREFIX.
(0018536)
Zalewa   
2017-10-11 19:32   
Quote

Wait for Zalewa to comment on "Do we care about this on other platforms?"
 and/or remove the comment in code (commit 2a58d7c).

The other platforms should not care about this, which either means that they should not receive it or it should be silently ignored. Context decides which is more appropriate. The question is: what would create more risk of causing unexpected behavior when the software is modified in the future?

Engines plugins on Windows are located in "engines/" directory located next to doomseeker.exe. We also try to load plugins from other directories, but on Windows there should be no reason to put any plugins anywhere else. Windows doesn't need to know about LIBDIR.

The comment can be changed to inform that "other platforms ignore this value, but it's provided for more convenience", or, the -DINSTALL_LIBDIR line can be 'if-UNIXed'.

Quote from "WubTheCaptain"
Doomseeker fails to execute on Xubuntu 16.04.3 LTS LiveCD, after sudo make install as instructed in COMPILE.txt.


I can reproduce this in Docker as well. Programs should run when make-installed after compiling them with defaults (even if explicit `ldconfig` is needed after make-installing), so I think this problem needs to be addressed.

It used to work before commit 2a58d7c832d9, after all. We can observe that /usr/local/lib is in ld.so.conf, but the arch directory is not:


root@33190085998f:/build# tail -n +1 /etc/ld.so.conf.d/*
==> /etc/ld.so.conf.d/fakeroot-x86_64-linux-gnu.conf <==
/usr/lib/x86_64-linux-gnu/libfakeroot

==> /etc/ld.so.conf.d/libc.conf <==
# libc default configuration
/usr/local/lib

==> /etc/ld.so.conf.d/x86_64-linux-gnu.conf <==
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

==> /etc/ld.so.conf.d/x86_64-linux-gnu_EGL.conf <==
/usr/lib/x86_64-linux-gnu/mesa-egl

==> /etc/ld.so.conf.d/x86_64-linux-gnu_GL.conf <==
/usr/lib/x86_64-linux-gnu/mesa

==> /etc/ld.so.conf.d/x86_64-linux-gnu_mirclientplatform.conf <==
/usr/lib/x86_64-linux-gnu/mir/clientplatform/mesa


What would be the correct approach here? Keep the RPATH to /usr/local/lib/<arch>?

Quote from "WubTheCaptain"

Does Doomseeker even need to know about lib or multiarch paths in src/core/datapaths.cpp, because ldconfig cache knows about those anyway?

Is it your suggestion that we should determine the correct path in the runtime instead? It should be doable, but Doomseeker will need to be self-aware about its own arch.

Quote from "Blzut3"

Right now Doomseeker only loads plugins from one directory and there's no elegant way for us to say "oh I got plugin X from an earlier directory therefore I should skip loading the one I found later." I don't know how symbol visibility plays into this, but I suspect that more needs to be done than load everything an unload/reject if the plugin matches something we loaded earlier. In any case this seems like a new feature not a packaging issue.


I can imagine someone wanting to put custom-built plugins into /usr/local/lib/, or even somewhere in $HOME. I can also imagine that probability of someone needing and/or doing this is... low.

1. Naive way: compare filenames, reject if the same filename is encountered more than once. Won't protect from `sudo cp libsrb2.so libsrb2_2.so`, but then again, screwing things up by doing this is possible already.

2. We already have an implicit requirement on plugins providing an unique string to be stored in doomseeker.ini. We can compare if this string duplicates and unload the duplicating plugin. Shared libs should leave no junk after unloading, unless we programmed them badly.
(0018539)
WubTheCaptain   
2017-10-12 05:48   
(edited on: 2017-10-12 05:54)
Quote from Zalewa
What would be the correct approach here? Keep the RPATH to /usr/local/lib/<arch>?


Good question.

/usr/local/lib is not meant to have tuples. That's not happening here, it's working as intended. Consider Debian doesn't use {,/usr}/lib64 (only the dynamic linker does), but /usr/lib/<tuple>[/<package>] and /usr/local/lib.

Here's an example from Debian buster/sid:

$ tail -n +1 /etc/ld.so.conf.d/*                                            
==> /etc/ld.so.conf.d/fakeroot-x86_64-linux-gnu.conf <==
/usr/lib/x86_64-linux-gnu/libfakeroot

==> /etc/ld.so.conf.d/libc.conf <==
# libc default configuration
/usr/local/lib

==> /etc/ld.so.conf.d/x86_64-linux-gnu.conf <==
# Multiarch support
/lib/x86_64-linux-gnu
/usr/lib/x86_64-linux-gnu

==> /etc/ld.so.conf.d/zz_i386-biarch-compat.conf <==
# Legacy biarch compatibility support
/lib32
/usr/lib32


RPATH will be gone from all libraries and executable binaries post-install. This is the intended/desired behavior.

sudo make install with default install prefix is not a very sane approach to install software anyway. If I created a Debian package out of this (using dpkg suite), it would be installed to /usr/lib/<tuple>/doomseeker of course and that wouldn't be an issue.

CMake's macro CMAKE_INSTALL_PREFIX defaults to /usr/local on UNIX.'https://cmake.org/cmake/help/latest/variable/CMAKE_INSTALL_PREFIX.html [^]'

Now I don't remember anymore after few days why linking failed to libwadseeker in this scenario, but I've known this issue since 1.1 because of lintian.

E: doomseeker: package-must-activate-ldconfig-trigger usr/lib/x86_64-linux-gnu/libwadseeker.so


Quote from Zalewa
Is it your suggestion that we should determine the correct path in the runtime instead? It should be doable, but Doomseeker will need to be self-aware about its own arch.


No, it was a mostly irrelevant suggestion.

Quote from Zalewa
even somewhere in $HOME


Irrelevant to this issue. Doomseeker already does dynamic linking for engines? Exporting LD_LIBRARY_PATH may be required for this use scenario anyway.

Quote from Zalewa
Naive way: compare filenames, reject if the same filename is encountered more than once. Won't protect from `sudo cp libsrb2.so libsrb2_2.so`, but then again, screwing things up by doing this is possible already.


SONAME? (0003242)
(0018540)
WubTheCaptain   
2017-10-12 05:59   
'https://lintian.debian.org/tags/package-modifies-ld.so-search-path.html [^]'

Quote
Packages containing shared libraries should either install them into /usr/lib or should require binaries built against them to set RPATH to find the library at run-time.
(0018541)
WubTheCaptain   
2017-10-12 06:14   
(edited on: 2017-10-12 06:16)
Zalewa: By the way, default instructions to sudo make install is broken in Doomseeker 1.1 too on this LiveCD.

Works after ldconfig trigger as it should.
(0018542)
WubTheCaptain   
2017-10-12 06:23   
Consider everything I said about Xubuntu LiveCD being broken to be out of scope for this ticket. It's a documentation issue with ldconfig step missing from COMPILE.txt. User-error of mine for forgetting to do it in first place.
(0018545)
Zalewa   
2017-10-12 17:24   
(edited on: 2017-10-12 17:26)
Post-2a58d7c832d9 it doesn't even work after `sudo ldconfig` for me, so 1.1 is less "broken".

1. ldconfig is not recursive
2. /usr/local/lib/x86_64-linux-gnu path is not in the default configuration
3. /usr/local/lib/x86_64-linux-gnu is the default path where Wadseeker is installed now.

Quote from "WubTheCaptain"
SONAME? (0003242)

The solution should be platform-agnostic - it should be possible to retrieve the equivalent PE executable metadata through WinAPI, but I'm not sold on anything that requires to write too much platform-dependant code.

Quote from "WubTheCaptain"
Doomseeker already does dynamic linking for engines?

Doomseeker doesn't have any dependancy on engines and has no knowledge of them whatsoever until they are loaded. The engines are loaded by listing files in known directories and trying to load those files as dynamic libraries with POSIX dlopen or WinAPI LoadLibrary, depending on the OS. See PluginLoader::filesInDir(), PluginLoader::PluginLoader() and PluginLoader::Plugin::Plugin(). This means that if you copy and paste chocolatedoom library 3 times you will end up with 3 Chocolate Dooms in your Doomseeker.
(0018546)
WubTheCaptain   
2017-10-12 17:57   
(edited on: 2017-10-12 17:58)
Quote from Zalewa
ldconfig is not recursive


This is correct.

Quote from Zalewa
/usr/local/lib/x86_64-linux-gnu path is not in the default configuration


This is also correct, it should not be in the default configuration. libc choice, and that path is bogus.

If post-2a58d7c832d9 installs to /usr/local/lib/x86_64-linux-gnu (which it doesn't on my machine/Xubuntu LiveCD), that's a bug. I can see there could be a way for this to happen at the moment.

Quote from Zalewa
/usr/local/lib/x86_64-linux-gnu is the default path where Wadseeker is installed now.


That shouldn't happen, and it didn't happen for me with Xubuntu LiveCD. We have a bug.

I tested this again with a Xubuntu LiveCD using Mercurial commit 1d768e9 for Doomseeker (2a58d7c832d9 + 11 newer commits).

-- Installing: /usr/local/lib/libwadseeker.so
(0018640)
Blzut3   
2017-10-29 01:07   
CPack generated debs should now trigger ldconfig and when installing outside of /usr there should be an RPATH set to keep the wadseeker link valid. Did I forget anything?
(0018652)
WubTheCaptain   
2017-10-29 18:10   
(edited on: 2017-10-29 18:12)
'https://bitbucket.org/Doomseeker/doomseeker/commits/2ee1fdeb200abe873671ee368226fb9e284f20fe [^]'
'https://bitbucket.org/Doomseeker/doomseeker/commits/33e6ab19ce75772b2b75156ba0a725014aa62f8a [^]'

I intent to review and test this later. I have a bad feeling about "something", but I'll test it first.

Quote from UpstreamGuide
Some projects include a rough /debian directory among source files to ease bleeding-edge package compilation and installation on Debian (and derived) systems. While this is a good effort, it is better to leave it out of the final tarball as it can interfere with debian's own packaging effort. Keeping it only in your VCS repository is usually a much saner default if it lives in a specific packaging branch, which mimics what Debian package maintainers do using git-buildpackage. Though leaving the debian folder in the normal branch can also interfere if the package maintainer is using an upstream git packaging workflow (for example: git tag based git-buildpackage workflow).


'https://wiki.debian.org/UpstreamGuide [^]' (but in this case, it's not exactly root except for wadseeker tarballs.)
(0018654)
Blzut3   
2017-10-29 18:38   
I could capitalize the directory name or something. Ultimately the only thing that matters to me is the file name is triggers since CPack only gives me the ability to dump files into the control archive with the name they have on disk.
(0019743)
WubTheCaptain   
2018-09-25 02:31   
I don't know, is this resolved?

Still loading from ~/.local/share on Debian GNU/Linux (buster/sid), which is arch-independent. There is ~/.local/lib available, though.

Pre-install:

$ ./doomseeker
[02:20:25] Starting Doomseeker. Hello World! :)
[02:20:25] Setting up data directories.
[02:20:25] Cache directory: /home/wub/.cache/doomseeker
[02:20:25] Config directory: /home/wub/.config/doomseeker
[02:20:25] Data directory: /home/wub/.local/share/doomseeker
[02:20:25] Attempting to load plugins from directory: /home/wub/.local/share/doomseeker/engines
[02:20:25] Attempting to load plugins from directory: /tmp/doomseeker-debian/doomseeker-1.2/obj-x86_64-linux-gnu/engines

[02:20:25] Loaded plugin: "Chocolate Doom"!
[02:20:25] Loaded plugin: "Odamex"!
[02:20:25] Loaded plugin: "Sonic Robo Blast 2"!
[02:20:25] Loaded plugin: "Turok 2 Remaster"!
[02:20:25] Loaded plugin: "Zandronum"!
[02:20:25] Listening to Zandronum's LAN servers broadcasts on port 15101.
[02:20:25] Initializing configuration file.
[02:20:25] Setting INI file: /home/wub/.config/doomseeker/doomseeker.ini
[02:20:25] Loading translations definitions
[02:20:25] Reading localizations definitions file: translations.def
[02:20:25] Initializing IP2C database.
[02:20:25] Initializing passwords configuration file.
[02:20:25] Initializing configuration for plugins.
[02:20:25] Initializing IRC configuration file.
[02:20:25] Setting IRC INI file: /home/wub/.config/doomseeker/doomseeker-irc.ini
[02:20:25] Starting refreshing thread.
[02:20:25] Preparing GUI.
[02:20:27] Please wait. IP2C database is being read. This may take some time.
[02:20:27] Parsing IP2C database: /home/wub/.local/share/doomseeker/IpToCountry.dat
[02:20:27] IP2C database read in 85 ms. Entries read: 158337
[02:20:27] Init finished.
================================
[02:20:27] IP2C parsing thread has finished.
[02:20:27] IP2C parsing finished.
[02:20:27] Total refresh initialized!
[02:20:30] Finished refreshing. Servers on the list: 557 (+1 custom, +0 LAN). Players: 47.


Lintian doesn't have an issue with ldconf:

$ lintian | grep ldconf
$


After install:

$ doomseeker
[02:30:47] Starting Doomseeker. Hello World! :)
[02:30:47] Setting up data directories.
[02:30:47] Cache directory: /home/wub/.cache/doomseeker
[02:30:47] Config directory: /home/wub/.config/doomseeker
[02:30:47] Data directory: /home/wub/.local/share/doomseeker
[02:30:47] Attempting to load plugins from directory: /home/wub/.local/share/doomseeker/engines
[02:30:47] Attempting to load plugins from directory: /usr/bin/engines
[02:30:47] Attempting to load plugins from directory: engines
[02:30:47] Attempting to load plugins from directory: /usr/lib/x86_64-linux-gnu/doomseeker/engines
[02:30:47] Loaded plugin: "Chocolate Doom"!
[02:30:47] Loaded plugin: "Odamex"!
[02:30:47] Loaded plugin: "Sonic Robo Blast 2"!
[02:30:47] Loaded plugin: "Turok 2 Remaster"!
[02:30:47] Loaded plugin: "Zandronum"!
[02:30:47] Listening to Zandronum's LAN servers broadcasts on port 15101.
[02:30:47] Initializing configuration file.
[02:30:47] Setting INI file: /home/wub/.config/doomseeker/doomseeker.ini
[02:30:47] Loading translations definitions
[02:30:47] Reading localizations definitions file: translations.def
[02:30:47] Initializing IP2C database.
[02:30:47] Initializing passwords configuration file.
[02:30:47] Initializing configuration for plugins.
[02:30:47] Initializing IRC configuration file.
[02:30:47] Setting IRC INI file: /home/wub/.config/doomseeker/doomseeker-irc.ini
[02:30:47] Starting refreshing thread.
[02:30:47] Preparing GUI.
[02:30:47] Please wait. IP2C database is being read. This may take some time.
[02:30:47] Parsing IP2C database: /home/wub/.local/share/doomseeker/IpToCountry.dat
[02:30:47] IP2C database read in 81 ms. Entries read: 158337
[02:30:47] Init finished.
================================
[02:30:47] IP2C parsing thread has finished.
[02:30:47] IP2C parsing finished.
[02:30:47] Total refresh initialized!
[02:30:50] Finished refreshing. Servers on the list: 557 (+1 custom, +0 LAN). Players: 52.


Uhh, /usr/bin/engines?
(0019744)
WubTheCaptain   
2018-09-25 02:34   
Quote from WubTheCaptain
I don't know, is this resolved?


1.2~beta-180925-0123 (e3f5bac45caa) if I may add (Mercurial source at default branch tip).

And no, I don't think this is resolved yet.
(0019999)
Blzut3   
2018-10-08 05:31   
The /usr/bin/engines thing was expected since that's just part of the normal search order (look in binary directory first and then check the install prefix). That said I suppose I could add logic to detect when we're installed and force the use of the installed plugins.

I think the ~/.local/share is just a hold over from when we didn't have a distinct concept of plugin search paths. Arguably we should support ~/.local/lib but like with /usr/local before, that's out of scope and would require support for multiple plugin directories to be useful.

'https://bitbucket.org/Doomseeker/doomseeker/commits/5532461c42b7cf453f269e44c90eb19bacf6f57f [^]'
(0020005)
WubTheCaptain   
2018-10-08 09:59   
Only "Attempting to load plugins from directory: /usr/lib/x86_64-linux-gnu/doomseeker/engines" remains after install, this is good. Thank you.
(0020006)
WubTheCaptain   
2018-10-08 10:01   
And "Attempting to load plugins from directory: /tmp/doomseeker-debian/doomseeker-1.2/obj-x86_64-linux-gnu/engines" pre-install, good.