Library and portability conflict

The concept of libraries has undergone some kind of modification over the past decade. The purpose of a library is to have a common place and resource for development of apps. On the PC we are dealing with a very strict guideline based from the the original 8088 processor of the 1980’s. Today the processor’s instruction set is 100% backward compatible. Libraries emerged to provide a common api reference to make programs smaller, more efficient, and sharable. SUCH IS NO LONGER THE CASE. I have many program languages on my PC and there is not one of them that runs properly! In each case it sites the libraries are not present for this or that feature. When you try and install the needed library you get conflicts that can only be resolved by damaging key systems need by the OS itself. So what’s the answer? Abandon libraries and code the each function with-in the program? Redefine with a form of segmentation. IE: 3 Library paths that are explicitly separate [OS / Dev / Usr] like 1990’s Mandrake release had. Don’t know quite how that system worked other than each language for dev had it own library folder. OS Libraries were in a system folder /lib/sys and usr lib were in /usr/lib (32bit so no lib64).

Here’s the kind of things I am facing.
SASM … CLI apps can be made but no GUI apps
NASM … CLI apps only
QT3 & 4 … installed ok but do not run
QT5 … doesn’t install 'nothing provides required libraries
kBasic … Kdevelop conflicts with installed library versions
RealBasic … nothing provides required dependencies
xBasic … installs but gives run time error “exception segmentation fault”

even gcc crashes when trying to compile ‘c’ code . upon compile it gives ‘error -2 exiting’

I have looked all over for a definitive list of library functions and the .dec info required to make headers and support so they can be used to develop a WORKING library to replace libaries that are no longer avail. I found 429 kernel level library reference but less than 100 give description of their use and even fewer give clue to how to implement calls. kdevelop referances again with no conclusive guide to the use. Then we ‘c’ / ‘c++’ which has tonnes of tiny routines embedded and like the others do not have clear info for their use.surely, there is a listing somewhere after 40 years of the PC that defines how to implement info. I have a 1969 book on unix that defines something like 9200 system calls and how to do them but of course don’t have a mainframe on my desktop. Have msdos system reference manual on calling the dos api and really obscure windows reference that lists 200 api calls with usage examples for maybe 20 or 30 but to date nothing that is for linux.

The major change between the 1990s and now, is that back then libraries were usually static, while now they are usually dynamic.

The pros and cons of static linking vs. dynamic linking have been argued for 20 years. Dynamic linking is pretty much the future, whether you like it or not.

Perhaps you have not yet adapted to this change.

Yes I know that I have been out of programing for 20+ years. A Quote for Unix sys admin bible (1969) states “Static linking to libraries has been thought to be the best practice as it forces strict adherence to the rules of tight efficient programing but at a cost of memory. As we move to more powerful demanding programs we need to do more dynamically it is only hoped that future programmers can find the road to being concise in their methods and documentation. You must remember that dynamically linked libraries are removed from memory once the last program referencing them has concluded. upon the next ocurance of the library being needed it may be loaded to a different boundary and if not coded correctly you can have serious segmentation faults that never existed in statics”.

I am not here to argue pros and cons if I must change so be it. My point is that I have no working program environment because I haven’t been able to figure how to include libraries so the *@$#^&$ programing environments can work. And to that end, I can’t even find the reference material that explains how to use them once I get a working programming environment. Right now all I have is pascal and fortran and asm that work for console apps only. They can do GUI stuff but only specify vague references to not included library packs.

I can switch to windows any version and accomplish what I need short of being able to function in linux real mode. I have no desire to forced back into the windows camp. Dynamic or Static either way I need definitive info that isn’t going to be obviscated at the next system change. In fact, I have already switched to windows in virtual space and updated numerous apps to run under windows. But linux is still a at a standstill. The list of dead PDE’s is growing exponencially.

My personal SOP is to create a virtual machine for each specific project so that the environment can be customized entirely with the requirements of that project and won’t be “contaminated” by anything else… Whether it’s different library versions, conflicting libraries, conflicting paths, etc. When you can maintain a “clean” development environment, then things work as expected, and any problems are surmountable.

Are you really coding only pascal and fortran and not more contemporary languages?


It has been a while so this is from memory.

Where the software includes libraries, I install those dynamic libraries to a suitable directory – usually in “/usr/local”. Then I set LD_RUN_PATH to include the directories where libraries are built for the final compile of the application. And that records in the binary, where it should look for its dynamic libraries.

I’m not a programmer, but a packager where come across all sorts of things… :wink:

Checking with pkg-config should show most info, or reference the relevant .pc file…?

Linker order, using --as-needed helps.

Can you give an example?

I have tried the virtual approach from a few languages to get them up and running.
Virtual1 linux leap15.1 with only one requirement to implement xForms - a gui development package for fast GUI design with concurent run debug of c - code , compliles to machine code through use of gcc. but when you try to compile it you get pages of bad links, library not present, proc failed … and look for libraries to install returns nothing provides the need resource. So I never get to the project stage even though I have a working virtual machine just needing a language that works.

Virtual2 linux leap 15.1 to implement kbasic unresolved dependencies, it doesn’t state what is missing

Virtual3 linux leap 15.1 Qt5_creator , QT5_creater ended with dependencies not met

Virtual4 linux leap 15.1 kdevelop same issue dependencies not met

In each of the 4 cases I installed lernel_develop , Xsystem_develop, and as many develop packages as I could find.

In frustration I tried installing Pascal and fortran and asm and they installed and even began to work but no GUI support and missing libraries for serious work. They do make a host of sample CLI programs. What became clear that unless your are a guru on that particular language there is no hope to use them. What wrong with a simple list of requirements as in
requires you not be using leap 15.1 because the dependencies are no longer available or
if you insist on using leap 15.1 you need the following things in addition to this program source and here are places you can try and get them…

result I deleted the installed languages the virtual drives so I am back to basic 15.1 installs and continued my efforts to find a compilable language to use … and no although ‘C’ is a contemporary language I hate it for the reason it is too cyptic to easy to make a misstake that can take 1000’s of grey hairs to resolve. Give me tried and true Assembly with reference material to interface with gui makes so much sense. At least with Assembly you have concise reference to the whole instruction set of the processor and can if you actually get reference to the gui stuff you can make progress. (I know you will then point out how the library of functions are Static)

On that last note this afternoon I finally recieved the Delux linux kernel reference book at 4741 pages of how the control the kernel using “C” and gcc. But again it specifically states only the standard ANSI C headers are discussed and most modern linux systems use a variant of ANSI ‘C’ and included 1000’s of routines in libraries that will not be discussed. I am 124 pages into the book and although it is good reference, and why it is important, so far it just talks about historical changes to linux.

Is pkg-config a cli command or is it something like QT5_creator-config , kdevelop-config no idea I call upon yast software install to install the language , then try to run it in hopes that it responds and has a help that actually works. It’s Linux who knows where it actually stores information and configs etc. I have found them all over the place and then have to search what they belong to. Like mbf-9.parm says when opened QT3_check valid = true as it’s only entry and in /usr/local so I can presume something relating the QT3 needs to know that info but who knows what?

Ok I guess I am lazy. went to cosole mode and checked out the info pkg-config and yes it defines all packages installed. It clearly shows the development packages I installed but none of the referenced missing libraries are in the list. zypper and yast software management doesn’t come up with any packages the contain the missing libraries. That huge manual I got this week states that on any compiled program the libraries must reside on the system that the program is ported to for it to work. It then states that in most linux distribution they break the library path by putting them else where during development. There are only 3 places that libraries should reside for a stable system and they are /lib/sys , /usr/lib , and usr/lib64. When software is packaged, the dynamic linked libraries that support the application must be packaged with the app and will install to one or more of the three required places. Putting them else where breaks the package.

Then we have another big issue with dynamic libraries in that one developer will keep the name of the library but modify it for a different purpose. Now you have 2 versions that are different purpose but same name. Ouch, Copy of windows dll hell.

Almost forces me into using gambas, perl, python which won’t work for the purposes that I need. I just need to build a gui display that compiles to machine code, most of them can be made work with very minimal ‘c’ coding because the underlying OS has the support with documentation on using it. I have the big book now and it does explain in depth for system level programmers and app level programmers alike.

So maybe I way to tackle this is to ask 1) which language has a good GUI develop system with run and debug, documentation, list of libraries and where to get them?

Well by default if you look at there are more, and you can then add you own location and just update the cache via ldconfig command (which is added as required in the %post/%postun in rpm packaging)…

cat /etc/
include /etc/*.conf
# /lib64, /lib, /usr/lib64 and /usr/lib gets added
# automatically by ldconfig after parsing this file.
# So, they do not need to be listed.

I run cuda, so have;

ls /etc/
cuda-10-1.conf  cuda-10-2.conf  graphviz.conf

cat /etc/

Also look at the ldd command…

Yes cuda looks impressive until it got to the point where you need to have a cuda capable GPU and that stops me cold. developing for the Raspberry Pi not possible, developing for the 60% of machine that don’t have an acceptable cuda enabled GPU also not possible. Then didn’t they say it runs python on the top application layer. Python can not be used in any mission critical application like navigation , charge rates or EV uses. I have intel graphics with openGL

Primary graphics on this desktop (You can see the setup in the screenshot subforum) is intel, have one nvidia gpu for cuda and one nvidia gpu for pci passthrough to kvm machines (development/test)… Both are cheap GT710’s and good enough for testing with. I have four RPI3’s, two run pihole dns (SLES 15 SP1 and Leap 15.1), one for development/packaging (Tumbleweed) and one for aircraft tracking (SLES 15 SP1) and runs gpsd for mlat calculations. I have a laptop running Tumbleweed and dual AMD GPU’s again for development/testing.

On the horizon is working on weather satellite data via the RPI3 :wink:

IMO an important foundation piece to being a developer is the ability to set up the Development Environment.
Look at your troubles as a necessary learning experience, not something that should be addressed with a magic few words of advice or wave of a wand. When I set up machines for my Developers, I don’t do that to help my Developers, I do it to standardize their build environments to maximize chances they generate compatible code. They should already know why they need what I give them.

I’m not sure what your reason may be for using KDE Development tools, but of course you’ll want or need to install in some version of KDE. Same thing for Qt development, you’ll want to install and develop only in KDE. A lightweight alternative to KDE is LXQt which is built on KDE Qt.

Depending on the libraries and framework for other coding, you may want to prefer a different Desktop.

Your missing dependencies is common, and is most often addressed by not installing the special repositories for the coding language and framework(s) you’re building. You have to know that the OSS only provides a basic collection of libraries commonly used for running apps and won’t typically be sufficient for building apps. Based on your posted list which suggests that you want to build Qt apps, install repos from the KDE repo wiki

If there are other languages and/or frameworks you wish to code, you need to either find those repos on your own or state those explicitly and someone can find appropriate repos. So, for instance if you intend to build fortran and pascal apps, I’d recommend a lighter DE like XFCE or LXQt and look for repos associated the tools and compilers for those languages.

A reminder, I wrote the following Wiki as a guide for finding files and packages


I’d be surprised of Python couldn’t be used for safety-critical applications, would be interested in what technical aspects might be deficient.
A quick Internet search returns plenty of hits about successfully using Python, of course often mentioned is that it can be important to know what kind of hardware you’re running on… If you’re running on under-powered hardware, then of course you can expect problems. But, nowadays even embedded/mobile hardware is powerful enough not to run into limitations unless you’re running something extremely large and complex. I do understand that if coding C you are able, and even required to handcraft process management and execution, but that involves its own set of problems.

If you coding to a spec that blacklists python, of course that’s altogether different than a technical choice.


Python is an interpretive language. 3 apps that I want to develop concern the total operational function of an electric vehicle (Dashboard, System controller, Charge and cabin controller). Siting Canadian and US laws governing implementing control systems for any automotive vehicle EV or otherwise, they state the language it is written in MUST be a compiled language and the implementation done in such a way that a general operator can not stop the program while it is running until it is safe to do so. (ie: your driving down the hiway and you close the program to the cli or gui without first making sure the vehicle is stopped and in park.) There listing of Programming platforms which are prohibited are Any form of non-compiled basic, Python, Jade, Java, Perl, VB or any other interpretive language. Acceptable languages include Assembly, c/c++, GTK, QT, xForms, xBasic and simular.

I understand their reasoning. In trying python there are are many ways you can kill a running process at any point. You can’t have that choice if it is controlling a 20 ton vehicle at high speed. So you have the computer boot right into the program without any chance to kill the program except by using the correct shutdown method. I tried it. write a script to start python and the and see if I could right in the middle kill the program ^c killed the program and exited the script to the cli ^Backspace did the same, click the ‘X’ top right of window did the same. In the compiled programs you can either not display the window dressings (so they can’t be used), and / or program the computer to trap and ignore ^C ^Backspace the operator must use the correct operation of bring the vehicle to a stop, Place it in Park, Choose ‘Turn off and disengage drive’. Even trying to stop the vehicle by turning off the ignition does not work until in Park.

I have been unsuccessful in getting xBasic to run in Linux but it does run in virtualbox - windows guest and it creates the compiled program for windows by making assembler output and compiling that but for windows.

While most of the programs I would do are not mission critical with regards to preventing forced program exiting and serious timing constraints, The EV development apps are time timing sensitive (1 millisecond or less). Even the overhead imposed in ‘C’ can be a problem. Add in the sluggish performance of an interpreter and the results can be catastrophic.

Which brings me full circle. Find a good GUI that both allows me to replicate the forms I have designed replicate the code in whatever language it needs and move on.

Cuda looked promising but I would need to add GPU’s for both my laptop and the RP3’s. Any programs I develop using cuda would also need the end user to add GPU’s if they don’t already have them so this is not a great option.

So my choice of language needs to be able to be able to run on both RP3 and opensuse leap 15.1. In both cases it needs both the libraries, headers, and gui needed to run the developed apps.

If I understand things right, If I install 3 repos using zypper ar -p 75 <url>, that will add the repo to my list of repos, lower it’s priority
so it takes precedence over higher ones. Then zypper -v dup --allowvender-change to update installed versions with vender change.

And this should get QT5 (Qt_creater) programming environment working. So I can see if it can do what I need??

Adding these repos to an existing installation:\

It's important to use a higher priority (which means a lower value!) than the main openSUSE repos and use zypper dup --allow-vendor-change for the switch (see Vendor change update).

1.Example: Latest KDE software releases on Leap 15.1:

zypper ar -p 75 KDE-Qt5
zypper ar -p 75 KDE-Frameworks
zypper ar -p 75 KDE-Applications
zypper -v dup --allow-vendor-change


The setup of the repositories is based on the distinction between three groups of packages, namely:

KDE Framework/Plasma packages. 
......This group contains the Framework libraries and the Plasma Workspace.
KDE Application packages. 
......This group contains the KDE Application releases, like Dolphin, Kdenlive, Konqueror, etc.
Packages for KDE/Qt based applications that are released independently from the major 
......KDE software releases. This group contains applications that are based on the 
......KDE or Qt libraries, like Krita, Konversation, Quassel, etc

3. Maintenance Updates
......Version: Leap 15.1 Shipped with Plasma 5.12.8 LTS, Applications 18.12.3 and KDE Frameworks 5.55.

4.What's available
For Users
......The latest KDE Frameworks 5 and Plasma releases, optionally Applications
.........These are newer versions of the Framework libraries and Plasma Desktop as released the KDE community, plus a number of openSUSE-specific patches. Optionally you can 
.........also get updated KDE Applications. These are delivered for at least the latest openSUSE
.........release and Tumbleweed. Depending on available versions of dependencies, these updates could
.........also be delivered for older, but supported, openSUSE versions. 

......KDE Applications 19.04 for Leap 15.1
.........KDE Applications 19.04 got released too late to be part of Leap 15.1, but are available 
.........using this repository.  

......KDE Extra
.........Newer versions of individual applications, KDE/Qt based (but not part of Frameworks, Plasma,
.........or Application releases), which have been packaged for released distributions. These newer
.........versions are building against diverse targets. This repository is maintained by the wider
.........openSUSE community.
5. Current repos
rick@linux-bdgk:~> zypper lr
Repository priorities are without effect. All enabled repositories share the same priority.

#  | Alias                               | Name                               | Enabled | GPG Check | Refresh
 1 | | home:ecsos                         | Yes     | (r ) Yes  | Yes    
 2 | | openSUSE:Factory                   | Yes     | (r ) Yes  | Yes    
 3 | | KDE:KDE3                           | Yes     | (r ) Yes  | Yes    
 4 | | KDE:Qt5                            | Yes     | (r ) Yes  | Yes    
 5 | | KDE:Frameworks5                    | Yes     | (r ) Yes  | Yes    
 6 | | home:Herbster0815                  | Yes     | (r ) Yes  | Yes    
 7 |    | libdvdcss repository               | Yes     | (r ) Yes  | Yes    
 8 |      | Packman Repository                 | Yes     | (r ) Yes  | Yes    
 9 | openSUSE-Leap-15.1-1                | openSUSE-Leap-15.1-1               | No      | ----      | ----   
10 | repo-debug                          | Debug Repository                   | No      | ----      | ----   
11 | repo-debug-non-oss                  | Debug Repository (Non-OSS)         | No      | ----      | ----   
12 | repo-debug-update                   | Update Repository (Debug)          | No      | ----      | ----   
13 | repo-debug-update-non-oss           | Update Repository (Debug, Non-OSS) | No      | ----      | ----   
14 | repo-non-oss                        | Non-OSS Repository                 | Yes     | (r ) Yes  | Yes    
15 | repo-oss                            | Main Repository                    | Yes     | (r ) Yes  | Yes    
16 | repo-source                         | Source Repository                  | No      | ----      | ----   
17 | repo-source-non-oss                 | Source Repository (Non-OSS)        | No      | ----      | ----   
18 | repo-update                         | Main Update Repository             | Yes     | (r ) Yes  | Yes    
19 | repo-update-non-oss                 | Update Repository (Non-Oss)        | Yes     | (r ) Yes  | Yes    

Unsure if the disabled repos should be just removed?

There is no need to change priorities, once you switch it will remain tied to that repository… mixing Factory, Leap and Home repositories is always a recipe for disaster.

So why do you not stick with supported products and repositories? If it’s not working then a bug report should be created? One of the benefits or running Tumbleweed something always new filtering through…

Just about zero need for libdvdcss repo active, it changes once in a blue moon, grab the src rpm and rebuild/install locally…

So, compile your Python code.
Don’t run it through an interpreter.


Another option is what used to be Iron Python, which was available both as its own IDE and as an extension to MS Visual Studio. I haven’t done anything recently with this but understand that it’s been absorbed into Visual Studio as a standard option today… Your python code is compiled into the dotNET CLR, so it runs like anything else that’s dotNET (including Mono).

I don’t know if there are other similar options where your Python code runs as a compiled executable.

This would be especially valuable if you’re coding for a RPi…
There is very little code available that’s not python. Or for that matter, I don’t know a single person who doesn’t code for RPi using Python (I’m a lonely guy who builds my RPi apps in Javascript). Python libraries and code are plentiful, which is important if you’re going to utilize the hardware in an RPi (vs something not hardware specific like deploying a website). I’m a lonely guy who writes apps for RPi in Javascript, and I need to use a special library to do so.

So, if compiled code is required, no big deal… You can write your code in Python taking advantage of enormous amounts of example code and libraries supporting a multitude of hardware options and compile the code for execution (and distribution).
The only thing that would make this unworkable is if you’re writing to a spec that blacklists Python specifically instead of specifying performance and reliability.


things haven’t really changed much from when I coded in binary / Hex / Oct of the 1960 / 70 era before we even had operating systems cli or gui. Knowing the hardware timing and constraints before committing the first byte to code was manditory. After all the computer didn’r even know how accept stuff from keyboard, tape, disk or anything. The raspberry Pi is like those early machines it needs to be taught what is expected of it. The RPI doesn’t have much in the way of memory and storage potential like the similar systems of 50 to 60 years ago. That clearly means you need one of three methods for serious work handling they are binary / Assembly / C\c++ There is no room for sloppy interpreters or compiling higher languages that were never meant to be compiled. BTW Python developers site even says compiling Python into machine code is a bad idea