Bug 1871655

What is the output of
# dnf list installed | grep nextcloud

nextcloud-client.x86_64                          2.6.5-6.fc33                        @fedora        
nextcloud-client-libs.x86_64                     2.6.5-6.fc33                        @fedora

# ls -lah /usr/lib64/nextcloud/

total 388K
drwxr-xr-x. 1 root root   64 Aug 23 13:08 .
dr-xr-xr-x. 1 root root 116K Aug 23 21:40 ..
lrwxrwxrwx. 1 root root   18 Aug  4 17:44 libocsync.so.0 -> libocsync.so.2.6.5
-rwxr-xr-x. 1 root root 383K Aug  4 17:45 libocsync.so.2.6.5

I don't know, nextclod libraries are correctly installed.
# dnf debuginfo-install nextcloud-client

$ gdb nextcloud-client
(gdb) run
(gdb) set height 0
and when the crash occurs, enter
(gdb) set print elements 0
(gdb) set print frame-arguments all
(gdb) thread apply all backtrace

Does running:
sudo /sbin/ldconfig

help?

Alas, ldconfig does not appear to have helped, Gwyn, but good suggestion, thanks!

Germano, the output/log info I'm seeing from gdb on the command "nextcloud" after running your suggested set of commands is:
  Starting program: /usr/bin/nextcloud 
  [Inferior 1 (process 2370) exited with code 0177]
  The only output I'm seeing from gdb is:

I should note that my system doesn't recognize nextcloud-client as a command--I've been running "nextcloud" as that's what was in the menu item's properties for the client.  Thought I'd added this in a prior comment before I had to head offline for that little while, but perhaps I failed to save changes before I left? *shrug*

At the moment I cannot help you, I am sorry

Ah well, thanks so much for your efforts to try :)

Maybe I'll find a suitable stick and go poke at people upstream later.  Or a carrot.

So, just to minorly update (although, alas, still not working)
On a friend's suggestion that perhaps my shared libs were only being loaded from the parent directory /usr/lib64 and not the subdirectory /nextcloud, tried creating another symlink in that directory. (And after taking a moment to double-check that I was putting the arguments in the right order, since I just don't create a lot of symlinks!)  Suppose I could equally have updated the LD_LIBRARY_PATH, but anyway...  

After creating said link within /usr/lib64 and running ldconfig, I didn't get the same "no such file or directory" message about libocsync.so.0 any more.  Instead, I see an immediate message that there's been a Segmentation fault :)  

I performed the same gdb commands as suggested above.

Output following the "run" command:
  Starting program: /usr/bin/nextcloud 
  [Thread debugging using libthread_db enabled]
  Using host libthread_db library "/lib64/libthread_db.so.1".
  [New Thread 0x7fffd970b640 (LWP 3018)]

  Thread 1 "nextcloud" received signal SIGSEGV, Segmentation fault.
  0x00007fffec686a7f in void doActivate<false>(QObject*, int, void**) () from /lib64/libQt5Core.so.5

And the backtrace output:
  Thread 2 (Thread 0x7fffd970b640 (LWP 3018)):
  #0  0x00007fffebfdda0f in poll () from /lib64/libc.so.6
  #1  0x00007fffea4a1842 in _xcb_conn_wait.part.0 () from /lib64/libxcb.so.1
  #2  0x00007fffea4a31cc in xcb_wait_for_event () from /lib64/libxcb.so.1
  #3  0x00007fffd9885c78 in QXcbEventQueue::run() () from /lib64/libQt5XcbQpa.so.5
  #4  0x00007fffec4c3690 in QThreadPrivate::start(void*) () from /lib64/libQt5Core.so.5
  #5  0x00007fffeb43f3f9 in start_thread () from /lib64/libpthread.so.0
  #6  0x00007fffebfe8b03 in clone () from /lib64/libc.so.6

  Thread 1 (Thread 0x7fffe72429c0 (LWP 3014)):
  #0  0x00007fffec686a7f in void doActivate<false>(QObject*, int, void**) () from /lib64/libQt5Core.so.5
  #1  0x00007fffecbb6ee6 in QGuiApplication::screenAdded(QScreen*) () from /lib64/libQt5Gui.so.5
  #2  0x00007fffecba6fd0 in QWindowSystemInterface::handleScreenAdded(QPlatformScreen*, bool) () from /lib64/libQt5Gui.so.5
  #3  0x00007fffd9889370 in QXcbConnection::initializeScreens() () from /lib64/libQt5XcbQpa.so.5
  #4  0x00007fffd9864b04 in QXcbConnection::QXcbConnection(QXcbNativeInterface*, bool, unsigned int, char const*) () from /lib64/libQt5XcbQpa.so.5
  #5  0x00007fffd9867893 in QXcbIntegration::QXcbIntegration(QStringList const&, int&, char**) () from /lib64/libQt5XcbQpa.so.5
  #6  0x00007ffff7fc75a3 in QXcbIntegrationPlugin::create(QString const&, QStringList const&, int&, char**) () from /usr/lib64/qt5/plugins/platforms/libqxcb.so
  #7  0x00007fffecbafbbf in QPlatformIntegrationFactory::create(QString const&, QStringList const&, int&, char**, QString const&) () from /lib64/libQt5Gui.so.5
  #8  0x00007fffecbba520 in QGuiApplicationPrivate::createPlatformIntegration() () from /lib64/libQt5Gui.so.5
  #9  0x00007fffecbbbb38 in QGuiApplicationPrivate::createEventDispatcher() () from /lib64/libQt5Gui.so.5
  #10 0x00007fffec65e3e9 in QCoreApplicationPrivate::init() () from /lib64/libQt5Core.so.5
  #11 0x00007fffecbbe508 in QGuiApplicationPrivate::init() () from /lib64/libQt5Gui.so.5
  #12 0x00007fffefe4fba0 in QApplicationPrivate::init() () from /lib64/libQt5Widgets.so.5
  #13 0x000055555570fceb in SharedTools::QtSingleApplication::QtSingleApplication (this=<optimized out>, appId=<optimized out>, argc=<optimized out>, argv=<optimized out>, this=<optimized out>, appId=<optimized out>, argc=<optimized   out>, argv=<optimized out>) at /usr/src/debug/nextcloud-client-2.6.5-6.fc33.x86_64/src/3rdparty/qtsingleapplication/qtsingleapplication.cpp:53
  #14 0x0000555555639a4c in OCC::Application::Application (this=<optimized out>, argc=<optimized out>, argv=<optimized out>, this=<optimized out>, argc=<optimized out>, argv=<optimized out>) at /usr/src/debug/nextcloud-client-2.6.5-6.fc33.x86_64/src/gui/application.cpp:104
  #15 0x0000555555606da8 in main (argc=<optimized out>, argv=0x7fffffffdf08) at /usr/src/debug/nextcloud-client-2.6.5-6.fc33.x86_64/src/gui/main.cpp:70

Whoever touched nextcloud-client with the latest commit broke it.

commit f0b4e9ec98204f4fd5b99575d24a5078650ca46d (HEAD -> master, origin/master, origin/f33, origin/HEAD)
Author: Mukundan Ragavan <nonamedotc>
Date:   Tue Aug 4 19:38:17 2020 -0400

    Change cmake macros to fix FTBFS

Included the change
 %build
-mkdir build
-pushd build
-%cmake_kf5 .. -DCMAKE_SHARED_LINKER_FLAGS="-Wl,--as-needed"
-make %{?_smp_mflags}
-popd
-
+%cmake -DCMAKE_SHARED_LINKER_FLAGS="-Wl,--as-needed"
+%cmake_build

the switch from %cmake_kf5 to %cmake , and the latter includes
-DCMAKE_SKIP_RPATH:BOOL=ON

which is what causes the ability to use the private libocsync.so.0 library to fail to be found.

I'll switch this back to %cmake_kf5

I have to take that back, latest %cmake macro appears to have dropped the CMAKE_SKIP_RPATH stuff, back to the drawing board.

A different quirk of the switch from %cmake_kf5 to %cmake , build log includes this snippet:

-- Set runtime path of "/builddir/build/BUILDROOT/nextcloud-client-2.6.5-6.fc33.x86_64/usr/lib64/libnextcloudsync.so.2.6.5" to "/usr//usr/lib64/nextcloud"
-- Installing: /builddir/build/BUILDROOT/nextcloud-client-2.6.5-6.fc33.x86_64/usr/lib64/libnextcloudsync.so
-- Installing: /builddir/build/BUILDROOT/nextcloud-client-2.6.5-6.fc33.x86_64/usr/bin/nextcloudcmd
-- Set runtime path of "/builddir/build/BUILDROOT/nextcloud-client-2.6.5-6.fc33.x86_64/usr/bin/nextcloudcmd" to "/usr//usr/lib64/nextcloud"

I made the cmake macro change to get it to build (based on what I saw on devel@ and docs?). 

Looks like it built fine but broke functionality. Grrr! :(

I would need help in fixing these EPEL 8 build errors
https://koji.fedoraproject.org/koji/taskinfo?taskID=50115893

https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-ddfb1b0ba4

should fix it (that build is added as epel8 buildroot override too)

should be built for epel8 (and epel8-playground) successfully now.

Thank you Rex!

Thank you to all involved, looking forward to testing on original machine + newly-Rawhided secondary Thinkpad :)

Mmmh the problem is happening again, I don't know why
https://bugzilla.redhat.com/show_bug.cgi?id=1792987#c26