Adding Library to Linux

This is a discussion on Adding Library to Linux within the Linux Programming forums, part of the Platform Specific Boards category; Hi I write a program with Qt (4.5.0) and now I want to run it on another system. Qt is ...

  1. #1
    Registered User
    Join Date
    Jul 2009
    Posts
    61

    Adding Library to Linux

    Hi
    I write a program with Qt (4.5.0) and now I want to run it on another system. Qt is installed there but the older version(4.3.1) there is a hard link file (libQtCore.so.4) to the libQtCore.4.3.1.

    What Can I do? Is there any LIB path in linux to do that? Placing the 4.5.0 library beside my bin file didn't work.

    Thank you everyone

  2. #2
    Making mistakes
    Join Date
    Dec 2008
    Posts
    476
    You probably mean LD_PATH. Just put it in /usr/bin and run ldconfig.

  3. #3
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,230
    I'm pretty sure you're going to need a few more libraries than just qtcore. First, figure out what you ACTUALLY need:

    Code:
    $ ldd MyProg
    This should dump a list of libraries. ALL of the listed libraries have to be available on the target system. (If these libraries dynamically load other libraries with dlopen(), you will not know what those libraries are until it fails at runtime)

    If you copy all of these libraries into the same directory as the program itself, it MIGHT work, if you start the program this way:

    Code:
    $ LD_LIBRARY_PATH=.:$LD_LIBRARY_PATH ./MyProg
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  4. #4
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by hosseinyounesi View Post
    Placing the 4.5.0 library beside my bin file didn't work.
    Dumb to potentially destructive* strategies is what you are attempting now. Why don't you just compile on the other system -- this makes way way more sense. That is why distros have binary packages, but trying to use those packages on a different distro is at best a crap shoot.

    You build a binary specifically for that system, and not try and run one from somewhere else. Chances are the two Qt versions are sufficiently similar and the compile will be fine.

    * eg, you could screw up the Qt installation that is already there and cause a problem for apps that were properly compiled on/for the other system. Everyone will love you then!
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  5. #5
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by brewbuck View Post
    If you copy all of these libraries into the same directory as the program itself, it MIGHT work, if you start the program this way:
    If this is for a system wide daemon or whatever as the OP has been talking about, I give you a very good chance of screwing up the local Qt, and maybe the C library itself, since those will probably turn out to be different versions too so you'll want to copy glibc into some directory and then add it to the LD_PATH; I'M GOING TO WARN YOU RIGHT NOW YOU CAN TOTALLY DISABLE AN ENTIRE SYSTEM THIS WAY, LIKE IT WILL START FAILING RIGHT AWAY, THEN CRASH TOTALLY AND NOT START OR RUN PROPERLY ANYMORE.

    hosseinyounesi, you are continuously proposing "bad hack" quickie solutions to problems that are arising because you are trying to accomplish something that is, plain and simple, beyond your current knowledge base and abilities. I guess that is okay, it's not going to injure anybody, but honestly: if you don't have time to learn to "do things right", then proceed with caution.
    Last edited by MK27; 07-28-2009 at 01:24 PM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  6. #6
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,230
    Quote Originally Posted by MK27 View Post
    If this is for a system wide daemon or whatever as the OP has been talking about, I give you a very good chance of screwing up the local Qt, and maybe the C library itself, since those will probably turn out to be different versions too so you'll want to copy glibc into some directory and then add it to the LD_PATH; I'M GOING TO WARN YOU RIGHT NOW YOU CAN TOTALLY DISABLE AN ENTIRE SYSTEM THIS WAY, LIKE IT WILL NOT START OR RUN PROPERLY ANYMORE.

    hosseinyounesi, you are continuously proposing "bad hack" quickie solutions to problems that are arising because you are trying to accomplish something that is, plain and simple, beyond your current knowledge base and abilities. I guess that is okay, it's not going to injure anybody, but honestly: if you don't have time to learn to "do things right", then proceed with caution.
    I don't think there's anything weird about this. Commercial closed-source Linux applications do it all the time. You do NOT have to change the system-wide LD_LIBRARY_PATH. The example shell code I gave changes it only for the process being launched.

    Typically you write a shell script which sets the library path correctly and then launches the program. Hell, even FireFox does this. The difficulty is finding the exact set of libraries that will be necessary. You do make a good point that these libraries might not be compatible with the runtime, in which case you'd have to install a compatible version of glibc and whatever else, like you said. But there is nothing UNSAFE about this, it's just hard to make it work.

    The alternative, of course, is to link statically. This usually works, as long as you stay away from a few problematic functions like dlopen() and gethostbyname().
    Last edited by brewbuck; 07-28-2009 at 12:35 PM.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  7. #7
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by brewbuck View Post
    You do NOT have to change the system-wide LD_LIBRARY_PATH. The example shell code I gave changes it only for the process being launched. But there is nothing UNSAFE about this, it's just hard to make it work.
    Okay, fair enough. I just wanted to make it clear that the safe and unsafe versions of the line in red could be very similar particularly if the OP intends to use an /etc/init.d script to invoke. I have f'd up the C library before; it ain't that hard to fix as long as you can mount the defunct system from somewhere and undo your changes.

    In fact (to do a total about face), you could stick the alternate QT libraries right into /usr/lib next to the ones that are there already, just don't put any softlinks to them!

    A big disadvantage to all these "no compile" options is that the app then becomes a total memory pig, which firefox is, because it uses libraries that are not shared by anything else*. If everybody and their uncle went around writing apps that needed their own special libraries because of source code restrictions, the whole thing would end up half as fast and twice as slow Qt is not lightweight -- we are talking a bunch of big fat libs for one (no offence) rinky dinky little app. Hopefully, the idea of being a software developer is to contribute functionality, and not reduce it so you can stick to your "business model".

    The attitude is "I don't care how many resources I waste as long as I can make my program work". Yuck. If you want to be a bad programmer who creates cruddy products, that's fine -- hopefully the users will blame "the system" and not you

    *which is still wierd, "Commercial closed-source Linux applications" being extremely limited in number. Most of them are port of things written for windows, so they are not depending on the linux version and could care less if it runs like tish because it's some huge fat statically linked beast, so I will stand by my assertion that the policy is to use a BAD HACK to make it work, and then dress this policy up because of course we are professionals, tee hee.
    Last edited by MK27; 07-28-2009 at 01:24 PM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  8. #8
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,230
    Quote Originally Posted by MK27 View Post
    A big disadvantage to this is that the app then becomes a total memory pig, which firefox is, because it uses libraries that are not shared by anything else*. If everybody and their uncle went around writing apps that needed their own special libraries because of source code restrictions, the whole thing would end up half as fast and twice as slow Qt is not lightweight -- we are talking a bunch of big fat libs for one (no offence) rinky dinky little app. Hopefully, the idea of being a software developer is to contribute functionality, and not reduce it so you can stick to your "business model".
    This isn't the developer's fault, IMHO. The problem lies with the library designers who are far too nonchalant about making breaking binary changes. Developers are trying to code against a moving target, and the most common response on the part of the library developers is "Just recompile it."

    Well, that solution doesn't work if you don't want to distribute source code. Or even if that's not the issue, the user may not have the ability or knowledge to recompile on his own system. The notion that each program should be compiled independently on the system it will ultimately run on is INSANE. This is nothing but pure laziness on the part of the library providers.

    There should be NO REASON why a program that was coded to version 4.x of some library should not be able to link against version 4.y of the same library where y is some number greater than x.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  9. #9
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by brewbuck View Post
    This isn't the developer's fault, IMHO. The problem lies with the library designers who are far too nonchalant about making breaking binary changes. Developers are trying to code against a moving target, and the most common response on the part of the library developers is "Just recompile it."

    Well, that solution doesn't work if you don't want to distribute source code.
    I think you said it right there. There is nothing wrong with compiling stuff from source at least on a per distro basis and this system in fact works very very well. You have software you want to distribute, you package it on a per system basis. Even MS software often comes in different versions, eg, one for XP and one for vista, etc.

    If you cannot do this because the source is not available, you are now asking other people (eg. the library developers) to bend over backward to suit your needs, which have nothing to do with producing quality software, etc, they are 100% about protecting a business model*. That is your choice so "the expense and inconvenience" is yours to deal with -- not something where you turn around and say oh, I think the open source community that produces the libraries, the entire system, 95% of the software etc, need to compromise their priorities and to waste their time to accommodate me because I can't find a way to make money without using a closed source, blah blah boo hoo -- well you see my point.

    *if I came on cboard and complained my code that you can't see doesn't work how much help should I expect with this problem from you?
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  10. #10
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,246
    If you cannot do this because the source is not available, you are now asking other people (eg. the library developers) to bend over backward to suit your needs, which have nothing to do with producing quality software, etc, they are 100% about protecting a business model*. That is your choice so "the expense and inconvenience" is yours to deal with -- not something where you turn around and say oh, I think the open source community that produces the libraries, the entire system, 95% of the software etc, need to compromise their priorities and to waste their time to accommodate me because I can't find a way to make money without using a closed source, blah blah boo hoo -- well you see my point.
    Hmm.. I disagree. Your library should have a static API that changes very rarely. If you (as a library developer) are modifying the API of your library with every release, that library better be in the alpha or beta stages. It's not that difficult to maintain backwards compatibility after your library reaches a mature state, and you owe it to the developers that use your library to keep it that way.

  11. #11
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,230
    Quote Originally Posted by MK27 View Post
    If you cannot do this because the source is not available, you are now asking other people (eg. the library developers) to bend over backward to suit your needs, which have nothing to do with producing quality software, etc, they are 100% about protecting a business model*.
    This has NOTHING to do with a business model. The problem affects open source software just as much as closed source. Even if the software is open source, it is a ridiculous requirement that the end user needs to compile the program himself in order to use it.

    (My username on Sourceforge is my first name. And I have a very common first name. If that gives you any indication of how long I've been dedicated to Open Source.)

    Linux as it currently stands is a freaking hellish monstrosity of libraries which are all changing WAY too fast. I've used Linux for a long time, since 1995. Believe me, it's getting worse. You can't install binary packages that are more than a few months out of date anymore. And no, I don't want to update my entire system just to get a single library with some extremely minor (but BINARY BREAKING) change in it in order to run a single program.

    It BLOWS.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  12. #12
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,230
    Quote Originally Posted by bithub View Post
    Hmm.. I disagree. Your library should have a static API that changes very rarely. If you (as a library developer) are modifying the API of your library with every release, that library better be in the alpha or beta stages. It's not that difficult to maintain backwards compatibility after your library reaches a mature state, and you owe it to the developers that use your library to keep it that way.
    Indeed. The excuse that all you need to do is recompile is just a way of shirking your own responsibility to follow well-founded development practices. And a library is a product, just as much as an application is. This attitude of "Bwahahaha, look what I, God, have wrought, and you shall take it AS IT IS" is just egotistical, naive, immature, and unprofessional.
    Code:
    //try
    //{
    	if (a) do { f( b); } while(1);
    	else   do { f(!b); } while(1);
    //}

  13. #13
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,246
    It BLOWS.
    This is why more and more developers are statically linking their libraries instead of relying on the user to ensure the correct libraries are installed. While static linking has its own issues, more and more people are deciding that it's the lesser of two evils.

  14. #14
    spurious conceit MK27's Avatar
    Join Date
    Jul 2008
    Location
    segmentation fault
    Posts
    8,300
    Quote Originally Posted by brewbuck View Post
    it is a ridiculous requirement that the end user needs to compile the program himself in order to use it.
    I never said this. I said compiled on a per distro basis. Intentionally or not, you have totally steered the discussion away from the point: compiling a binary *once* on a single linux machine and then trying to make arrangements so you can port that single binary to every "linux machine" out there is PREPOSTEROUS. Why not just do it on one single computer and then demand that all the other computers in the world conform to your desire to have this binary run on every single one, regardless of OS, user preferences, etc. etc., regardless of what the consequences will be for all those other computers which are not and never were, yours?

    (My username on Sourceforge is my first name. And I have a very common first name. If that gives you any indication of how long I've been dedicated to Open Source.)
    Finally, the man behind fred.sf.net is revealed.

    Linux as it currently stands is a freaking hellish monstrosity of libraries which are all changing WAY too fast. I've used Linux for a long time, since 1995. Believe me, it's getting worse. You can't install binary packages that are more than a few months out of date anymore. And no, I don't want to update my entire system just to get a single library with some extremely minor (but BINARY BREAKING) change in it in order to run a single program.
    #1) you are whining way too hard here for me to take you seriously on this, I've been using linux for a decade and do not feel in the least put out by minor challenges like that (and I don't believe you are that stupid, either); if the computer could just provide you with everything you want without putting any thought into it, you wouldn't need a keyboard. Methinks the "solutions" you imply amount to a sabotaging of something. Linux is "a freaking hellish monstrosity" of everything -- please do not try to fix it in favour of whatever boring monolithic vision you are trying to evoke.

    Although this may hamper someone's desire to write and disseminate "the program" (favoured by 100% percent of today's computer users!) in a single financial quarter...oh well!

    Please read Kafka'sThe Great Wall of China if you want to dig my groove about this part Honestly.
    Last edited by MK27; 07-28-2009 at 04:36 PM.
    C programming resources:
    GNU C Function and Macro Index -- glibc reference manual
    The C Book -- nice online learner guide
    Current ISO draft standard
    CCAN -- new CPAN like open source library repository
    3 (different) GNU debugger tutorials: #1 -- #2 -- #3
    cpwiki -- our wiki on sourceforge

  15. #15
    Registered User
    Join Date
    Sep 2004
    Location
    California
    Posts
    3,246
    I've been using linux for a decade and do not feel in the least put out by minor challenges like that
    Keyword here being using. I'm willing to bet you have not been doing application development on Linux for a decade, otherwise you would feel our pain here.

Page 1 of 2 12 LastLast
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. dlopen, dlsym does not work in Linux as expected
    By balakv in forum C Programming
    Replies: 2
    Last Post: 04-03-2007, 12:44 AM
  2. SVN Import Causes Crash
    By Tonto in forum Tech Board
    Replies: 6
    Last Post: 11-01-2006, 02:44 PM
  3. Problems adding a user in linux
    By axr0284 in forum Tech Board
    Replies: 1
    Last Post: 12-10-2004, 08:13 AM
  4. installing linux for the first time
    By Micko in forum Tech Board
    Replies: 9
    Last Post: 12-06-2004, 04:15 AM
  5. linux vs linux?
    By Dreamerv3 in forum Linux Programming
    Replies: 5
    Last Post: 01-22-2002, 08:39 AM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21