JLink broken Linux RPM install packages

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • JLink broken Linux RPM install packages

    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))
  • RE: JLink broken Linux RPM install packages

    v01d wrote:

    .

    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.....


    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 ...

    The post was edited 1 time, last by v01d ().

  • Hello,

    Thank you for your inquiry.
    We tried to reproduce the issue with a Fedora 27 VM 64-bit in VMware.
    The VM is a default installation that has not seen any SEGGER software before.
    For testing we used J-Link software V6.30f and for installation the 64-bit RPM package.
    After installing the software by simply double clicking the RPM package and selecting Install in the Fedora software installer we tried to launch the JLinkGDBServerExe.
    First over CL, then per double click. Both worked the same. Picture is attached.

    Do you have some custom installation of Fedora?
    Did you run the J-Link installer with sudo?

    Best regards,
    Nino
    Images
    • Capture.PNG

      215.74 kB, 1,145×618, viewed 551 times
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • 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 .. "

    The post was edited 2 times, last by v01d ().

  • Hello,

    I talked to our IT guy and he said that all our test VMs were standard installations without any extra installation steps. So according to him he did not install any Qt version extra.
    For installation we used the official Fedora workstation version: getfedora.org/en/workstation/download/

    Here is the requested output:

    Source Code

    1. ldd $(which JLinkGDBServerExe)
    2. linux-vdso.so.1 (0x00007ffc8d71e000)
    3. libQtGui.so.4 => /lib64/libQtGui.so.4 (0x00007fd99eb13000)
    4. libQtCore.so.4 => /lib64/libQtCore.so.4 (0x00007fd99e60f000)
    5. librt.so.1 => /lib64/librt.so.1 (0x00007fd99e407000)
    6. libdl.so.2 => /lib64/libdl.so.2 (0x00007fd99e203000)
    7. libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fd99dfe4000)
    8. libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fd99dc5e000)
    9. libm.so.6 => /lib64/libm.so.6 (0x00007fd99d909000)
    10. libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fd99d6f2000)
    11. libc.so.6 => /lib64/libc.so.6 (0x00007fd99d30f000)
    12. libgthread-2.0.so.0 => /lib64/libgthread-2.0.so.0 (0x00007fd99d10d000)
    13. libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x00007fd99cdf9000)
    14. libpng16.so.16 => /lib64/libpng16.so.16 (0x00007fd99cbc6000)
    15. libz.so.1 => /lib64/libz.so.1 (0x00007fd99c9af000)
    16. libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007fd99c6fa000)
    17. libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x00007fd99c4a7000)
    18. libSM.so.6 => /lib64/libSM.so.6 (0x00007fd99c29f000)
    19. libICE.so.6 => /lib64/libICE.so.6 (0x00007fd99c083000)
    20. libXi.so.6 => /lib64/libXi.so.6 (0x00007fd99be72000)
    21. libXrender.so.1 => /lib64/libXrender.so.1 (0x00007fd99bc68000)
    22. libXrandr.so.2 => /lib64/libXrandr.so.2 (0x00007fd99ba5d000)
    23. libXfixes.so.3 => /lib64/libXfixes.so.3 (0x00007fd99b857000)
    24. libXcursor.so.1 => /lib64/libXcursor.so.1 (0x00007fd99b64c000)
    25. libXinerama.so.1 => /lib64/libXinerama.so.1 (0x00007fd99b449000)
    26. libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x00007fd99b204000)
    27. libXext.so.6 => /lib64/libXext.so.6 (0x00007fd99aff2000)
    28. libX11.so.6 => /lib64/libX11.so.6 (0x00007fd99acb4000)
    29. /lib64/ld-linux-x86-64.so.2 (0x00007fd99f83a000)
    30. libpcre.so.1 => /lib64/libpcre.so.1 (0x00007fd99aa41000)
    31. libbz2.so.1 => /lib64/libbz2.so.1 (0x00007fd99a830000)
    32. libffi.so.6 => /lib64/libffi.so.6 (0x00007fd99a628000)
    33. libuuid.so.1 => /lib64/libuuid.so.1 (0x00007fd99a423000)
    34. libexpat.so.1 => /lib64/libexpat.so.1 (0x00007fd99a1f1000)
    35. libxcb.so.1 => /lib64/libxcb.so.1 (0x00007fd999fc9000)
    36. libXau.so.6 => /lib64/libXau.so.6 (0x00007fd999dc5000)
    Display All


    Please understand that we can't give support for all the spinoff versions of Linux derivates and will only focus on the most popular and "official" ones.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • 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
  • Hello,

    The different Qt versions used throughout our software is due to historical reasons.
    We are in process of streamlining it so all use the same version.
    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.

    Best regards,
    Nino
    Please read the forum rules before posting.

    Keep in mind, this is *not* a support forum.
    Our engineers will try to answer your questions between their projects if possible but this can be delayed by longer periods of time.
    Should you be entitled to support you can contact us via our support system: segger.com/ticket/

    Or you can contact us via e-mail.
  • 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)