The JLink RPM installers for Linux 64-bit are partially broken since V6.30 to current inclusive, imho.

The problem that I saw, relates to introduction of GDBServer GUI version, which appears to be Qt based.
This new dependency is not reflected in the installation packages, and thus are partially broken.

Consider

rpm -qpi --requires /media/sf_dloads/Segger/JLink_Linux_V630f_x86_64.rpm
Name : jlink
Version : 6.30.6
Release : 1
Architecture: x86_64
Install Date: (not installed)
Group : Development/Tools
Size : 63516474
License : Proprietary
Signature : (none)
Source RPM : jlink-6.30.6-1.src.rpm
Build Date : Sat 03 Mar 2018 03:31:44 AM AEDT
Build Host : RedHat-6.4-VM
Relocations : (not relocatable)
Packager : SEGGER
Vendor : SEGGER Microcontroller GmbH
URL : segger.com
Summary : SEGGER J-Link tools
Description :
This package provides software tools
for SEGGER J-Link debug probes.
ncurses >= 5.5
glibc >= 2.5
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadIsXz) <= 5.2-1

No Qt gui dependency.

I reported similar issue for SystemView installation RPMs here:
https://forum.segger.com/index.php?page=Thread&threadID=4885

There is thus bunch of SystemView broken RPMs too.


(On the other note, is /bin a good place for symlinks to /opt/SEGGER/xxxx ? Shouldn't this be in /usr/bin ? (if not /usr/local/bin))

Ok, correction, I see that , unlike SystemView, JLink package contains needed Qt inside it. Same as Ozone, which is great.

But executing JLinkGDBServerExe from command line would through me missing libQtGui.so .. So on my system, it does not find it.
Does install may be miss ldconfig path ?

"JLinkGDBServerExe
JLinkGDBServerExe: error while loading shared libraries: libQtGui.so.4: cannot open shared object file: No such file or directory



ldd /bin/JLinkGDBServerExe
linux-vdso.so.1 (0x00007fff591e3000)
libQtGui.so.4 => not found
libQtCore.so.4 => not found
librt.so.1 => /lib64/librt.so.1 (0x00007f2d803c1000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f2d801bd000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f2d7ff9e000)
libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007f2d7fc17000)
libm.so.6 => /lib64/libm.so.6 (0x00007f2d7f8c2000)
libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007f2d7f6ab000)
libc.so.6 => /lib64/libc.so.6 (0x00007f2d7f2c8000)
/lib64/ld-linux-x86-64.so.2 (0x00007f2d805c9000)


echo "/opt/SEGGER/JLink/" >> /etc/ld.so.conf


ldd /bin/JLinkGDBServerExe
linux-vdso.so.1 (0x00007ffe647e2000)
libQtGui.so.4 => /opt/SEGGER/JLink/libQtGui.so.4 (0x00007f3b05f9d000)
libQtCore.so.4 => /opt/SEGGER/JLink/libQtCore.so.4 (0x00007f3b05aad000)


"


Which would work, but prob not very good, as Ozone, JLink, and SystemView (which is missing Qt lib all together) seems on different revisions of Qt ...

Hello,

My Fedora is a 'standard' variant, with LXDE desktop. Note, no Qt installed by default (and one not necc. needs it).

I think, if you start on your Fedora by first un-installing package qt-x11, you might get the behavior.

Could you share output of ldd JLinkGDBServerExe?

Output for me after I've installed Fedora's Qt:

ldd $(which JLinkGDBServerExe)
linux-vdso.so.1 (0x00007ffce67d6000)
libQtGui.so.4 => /lib64/libQtGui.so.4 (0x00007ff16c62d000)
libQtCore.so.4 => /lib64/libQtCore.so.4 (0x00007ff16c129000)

Which is not the desired setup, my guess? As these provided in /opt/SEGGER/JLink/.

All installations are done by " sudo dnf install .. "

Hi,

From your output you pasted :

libQtGui.so.4 => /lib64/libQtGui.so.4 (0x00007fd99eb13000)
libQtCore.so.4 => /lib64/libQtCore.so.4 (0x00007fd99e60f000)

If this is what was intended, and expected situation, then , referring to my original first post, your JLink packages are broken: they don't specify required dependency.

May be you need to run it by your developers, to make sure this is expected dynamic linking. As, question is, why were then Qt libraries also included in the >=6.30 JLink packages, as part of the installation, into the /opt/Segger/JLink path. May be they intended that not to happen (but guy who packaged it went otherwise ..).

Also note that yet another set of Qt libraries (and I think of different version ..) is included in SES standard installation path. And SES binary resolves those Qt to be used on the host ones.
And yet another of Qt libraries is included as part of your Ozone installation ..

So are these all sloppy(over including files) packaging and the expectation is that Linux host disto has the required Qt libs and of right version?

But as I mention, for case of SystemView, it didn't come with your own Qt libs .. Yet, the RPM has no spec of Qt dependency at all .

VMs were standard installations without any extra installation steps. So according to him he did not install any Qt version extra

... Linux derivates and will only focus on the most popular and "official" ones.

This is irrelevant. Installed he or not Qt, and spin off or official. They use the same package management, and you supply RPM. Dependency must be spec'ed so that it's picked up by the installer when installing.
(In particular, as different parts of the soft - Jlink, SystemView, Ozone, SES - may use different libraries versions. )

Or your Release notes should specify exactly which version of Qt libraries you require for which package.

Don't you think this is reasonable

Hi,

However we will not include Qt dependencies in all our software. Instead there will be a white list of recommended Linux versions to use as reference.

What I was trying to highlight and it may seem not understood, is that you don't have to include it, you have to specify in the RPM spec that it is required as a dependency.
And thus the package manager shall either pull & install the dependency, or fail to install if not available.
This is the main point, NOT that you need to include any Qt inside your package.
The recommended distros & configuration of will work, but RPM will continue to be broken if you don't specify all the deps.

Regards.

(Please close this thread)