Page 1 of 3 123 LastLast
Results 1 to 10 of 26

Thread: Library and portability conflict

  1. #1
    Join Date
    Jul 2009
    Location
    Rockyford Alberta Canada
    Posts
    1,388

    Default 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'
    When your up to your a** in Alligators it's pretty hard to remember you intended to drain the swamp (author unknown)

  2. #2
    Join Date
    Jul 2009
    Location
    Rockyford Alberta Canada
    Posts
    1,388

    Default Re: Library and portability conflict

    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.
    When your up to your a** in Alligators it's pretty hard to remember you intended to drain the swamp (author unknown)

  3. #3
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    13,310
    Blog Entries
    3

    Default Re: Library and portability conflict

    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.
    openSUSE Leap 15.1; KDE Plasma 5;
    testing Leap 15.2Alpha

  4. #4
    Join Date
    Jul 2009
    Location
    Rockyford Alberta Canada
    Posts
    1,388

    Default Re: Library and portability conflict

    Quote Originally Posted by nrickert View Post
    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.
    When your up to your a** in Alligators it's pretty hard to remember you intended to drain the swamp (author unknown)

  5. #5
    Join Date
    Jun 2008
    Location
    San Diego, Ca, USA
    Posts
    12,004
    Blog Entries
    2

    Default Re: Library and portability conflict

    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?

    TSU
    Beginner Wiki Quickstart - https://en.opensuse.org/User:Tsu2/Quickstart_Wiki
    Solved a problem recently? Create a wiki page for future personal reference!
    Learn something new?
    Attended a computing event?
    Post and Share!

  6. #6
    Join Date
    Aug 2010
    Location
    Chicago suburbs
    Posts
    13,310
    Blog Entries
    3

    Default Re: Library and portability conflict

    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.
    openSUSE Leap 15.1; KDE Plasma 5;
    testing Leap 15.2Alpha

  7. #7
    Join Date
    Jun 2008
    Location
    Podunk
    Posts
    28,087
    Blog Entries
    15

    Default Re: Library and portability conflict

    Hi
    I'm not a programmer, but a packager where come across all sorts of things....

    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?
    Cheers Malcolm °¿° SUSE Knowledge Partner (Linux Counter #276890)
    SUSE SLE, openSUSE Leap/Tumbleweed (x86_64) | GNOME DE
    If you find this post helpful and are logged into the web interface,
    please show your appreciation and click on the star below... Thanks!

  8. #8
    Join Date
    Jul 2009
    Location
    Rockyford Alberta Canada
    Posts
    1,388

    Default Re: Library and portability conflict

    Quote Originally Posted by tsu2 View Post
    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?

    TSU
    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
    Qt5_creater
    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.
    When your up to your a** in Alligators it's pretty hard to remember you intended to drain the swamp (author unknown)

  9. #9
    Join Date
    Jul 2009
    Location
    Rockyford Alberta Canada
    Posts
    1,388

    Default Re: Library and portability conflict

    Quote Originally Posted by malcolmlewis View Post
    Hi
    I'm not a programmer, but a packager where come across all sorts of things....

    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?
    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?
    When your up to your a** in Alligators it's pretty hard to remember you intended to drain the swamp (author unknown)

  10. #10
    Join Date
    Jul 2009
    Location
    Rockyford Alberta Canada
    Posts
    1,388

    Default Re: Library and portability conflict

    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?
    Last edited by techwiz03; 11-Dec-2019 at 16:30. Reason: typos
    When your up to your a** in Alligators it's pretty hard to remember you intended to drain the swamp (author unknown)

Page 1 of 3 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •