Building a sample application with libraries located in nonstandard directory

Discussion in 'C Programming' started by ArifulHossain tuhin, Jan 7, 2012.

  1. I have built a library. Say its libexample.la. Now i want a build a sample application. The sample application comes with a configure script. When i run the configure script it fails reporting that it could not find the library it needs. So i need to supply the libexample.la's directory information in the configure script somehow so that it can find the library and build the application. I need a general way of doing this, because i stumble upon this problem several times in past.

    I always solved it through googling, and some tweaking with no clear understanding. I have idea that may be it can be done through defining Environment variables. But any general way of doing it? i mean to supply this information to the configure script in a way which will be applicable to all otherscenario ?
    Thanks in advance.
    ArifulHossain tuhin, Jan 7, 2012
    #1
    1. Advertising

  2. ArifulHossain tuhin

    ec429 Guest

    Re: Building a sample application with libraries located in nonstandarddirectory

    On 07/01/12 11:26, ArifulHossain tuhin wrote:
    > I have built a library. Say its libexample.la. Now i want a build a sample application. The sample application comes with a configure script. When i run the configure script it fails reporting that it could not find the library it needs. So i need to supply the libexample.la's directory information in the configure script somehow so that it can find the library and build the application. I need a general way of doing this, because i stumble upon this problem several times in past.
    >
    > I always solved it through googling, and some tweaking with no clear understanding. I have idea that may be it can be done through defining Environment variables. But any general way of doing it? i mean to supply this information to the configure script in a way which will be applicable to all other scenario ?
    > Thanks in advance.

    This is not a C question. You might have better luck asking in a
    newsgroup devoted to your platform; may I suggest comp.unix.programmer?
    -e
    --
    'sane', adj.: see 'unimaginative'
    on the web - http://jttlov.no-ip.org
    ec429, Jan 7, 2012
    #2
    1. Advertising

  3. Re: Building a sample application with libraries located in nonstandarddirectory

    In article <je9k2a$ste$>, ec429 <> wrote:
    >On 07/01/12 11:26, ArifulHossain tuhin wrote:
    >> I have built a library. Say its libexample.la. Now i want a build a

    >sample application. The sample application comes with a configure
    >script. When i run the configure script it fails reporting that it could
    >not find the library it needs. So i need to supply the libexample.la's
    >directory information in the configure script somehow so that it can
    >find the library and build the application. I need a general way of
    >doing this, because i stumble upon this problem several times in past.
    >>
    >> I always solved it through googling, and some tweaking with no clear

    >understanding. I have idea that may be it can be done through defining
    >Environment variables. But any general way of doing it? i mean to supply
    >this information to the configure script in a way which will be
    >applicable to all other scenario ?
    >> Thanks in advance.

    >This is not a C question. You might have better luck asking in a
    >newsgroup devoted to your platform; may I suggest comp.unix.programmer?
    >-e
    >--
    >'sane', adj.: see 'unimaginative'
    > on the web - http://jttlov.no-ip.org


    IOW:

    Off topic. Not portable. Cant discuss it here. Blah, blah, blah.

    --
    Useful clc-related links:

    http://en.wikipedia.org/wiki/Aspergers
    http://en.wikipedia.org/wiki/Clique
    http://en.wikipedia.org/wiki/C_programming_language
    Kenny McCormack, Jan 7, 2012
    #3
  4. ec429 <> wrote:
    > On 07/01/12 11:26, ArifulHossain tuhin wrote:
    > > I have built a library. Say its libexample.la. Now i want a build a sample
    > >application. The sample application comes with a configure script. When i
    > >run the configure script it fails reporting that it could not find the
    > >library it needs. So i need to supply the libexample.la's directory
    > >information in the configure script somehow so that it can find the library
    > >and build the application. I need a general way of doing this, because i
    > >stumble upon this problem several times in past.


    > > I always solved it through googling, and some tweaking with no clear
    > >understanding. I have idea that may be it can be done through defining
    > >Environment variables. But any general way of doing it? i mean to supply
    > >this information to the configure script in a way which will be applicable
    > >to all other scenario ?


    > This is not a C question. You might have better luck asking in a
    > newsgroup devoted to your platform; may I suggest comp.unix.programmer?


    Seconded. And while doing that it might be worth to try to
    give some further information about what you're doing (e.g.
    what does this configure script do, where does it come from
    etc. - is this a question about the autoconf/automake tools
    in disguise?). And, btw., at least under Unix the extension
    for a library is typically '.a' (for static libraries) and
    '.so' (for shared libraries) and '.la' is often an interme-
    diate file created by the libtool utility. If you use these
    tools it would make a lot of sense if you would mention that
    in your post.
    Regards, Jens
    --
    \ Jens Thoms Toerring ___
    \__________________________ http://toerring.de
    Jens Thoms Toerring, Jan 7, 2012
    #4
  5. ArifulHossain tuhin

    Kaz Kylheku Guest

    Re: Building a sample application with libraries located innonstandard directory

    On 2012-01-07, ArifulHossain tuhin <> wrote:
    > I need a general way of doing this, because i stumble upon this
    > problem several times in past.


    There is no general way of doing it because every program's configure
    script is different.

    Autoconf is a braindamaged pile of crap designed by imbeciles, but naive
    developers keep trusting that it will take care of their build problems
    somehow.

    However, I'm surprised you're having that much trouble. This stuff
    generally works if you're building packages using a machine's native
    toolchain, to be installed in standard locations on that machine.

    > I always solved it through googling, and some tweaking with no clear
    > understanding. I have idea that may be it can be done through defining
    > Environment variables.


    Environment variables can indeed influence configure scripts, and this can be a
    huge time saver. For instance, most of the cross-compiling idiocies in the bash
    configure script can be circumvented by hard-coding the answers to some of
    those tests and exporting them as environment variables. In Autoconf-generated
    scripts, you usually have to use internal variables for this which are named
    something like ac_config_whatever, or something similar.

    There is not 100% consistent convention. You have to read the configure
    script to see where the decision is being made which is going wrong,
    and which environment variable it hinges on, if any, etc.

    > But any general way of doing it?


    Hahaha.
    Kaz Kylheku, Jan 7, 2012
    #5
  6. ArifulHossain tuhin

    Seebs Guest

    Re: Building a sample application with libraries located innonstandard directory

    On 2012-01-07, Kaz Kylheku <> wrote:
    > Autoconf is a braindamaged pile of crap designed by imbeciles, but naive
    > developers keep trusting that it will take care of their build problems
    > somehow.


    This is unduly harsh. Autoconf is not nearly as stupid as it looks; it's just
    that 90% of the things it does which look stupid are only sensible if you
    assume that it matters whether stuff builds on Ultrix or SVR2. Which most of
    the stuff using it wouldn't anyway.

    (Not really C-related directly, but many C programmers get stuck trying to
    outsmart autoconf.)

    -s
    --
    Copyright 2011, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
    Seebs, Jan 7, 2012
    #6
  7. ArifulHossain tuhin

    ec429 Guest

    [OT] Bashing on autotools (Was: Building a sample application withlibraries located in nonstandard directory)

    On 07/01/12 21:24, Seebs wrote:
    > On 2012-01-07, Kaz Kylheku<> wrote:
    >> Autoconf is a braindamaged pile of crap designed by imbeciles, but naive
    >> developers keep trusting that it will take care of their build problems
    >> somehow.

    >
    > This is unduly harsh. Autoconf is not nearly as stupid as it looks; it's just
    > that 90% of the things it does which look stupid are only sensible if you
    > assume that it matters whether stuff builds on Ultrix or SVR2. Which most of
    > the stuff using it wouldn't anyway.
    >
    > (Not really C-related directly, but many C programmers get stuck trying to
    > outsmart autoconf.)
    >
    > -s

    Or you can write POSIX-compliant code, refuse to support
    non-POSIX-compliant platforms, and chuck Autoconf in /dev/dustbin where
    it belongs.
    Besides, even if you believe Autoconf's use case is valid, Autoconf is
    not a well-designed solution to that problem; simply put, it's hairy.
    -e
    --
    'sane', adj.: see 'unimaginative'
    on the web - http://jttlov.no-ip.org
    ec429, Jan 8, 2012
    #7
  8. Re: Building a sample application with libraries located innonstandard directory

    In article <>,
    Kaz Kylheku <> wrote:
    >
    >Autoconf is a braindamaged pile of crap designed by imbeciles, but naive
    >developers keep trusting that it will take care of their build problems
    >somehow.


    Amen. I've used autoconf on occasion, and my experience has been that
    it's more work to get the autoconf scripts working than it would have
    been to write portable code in the first place.

    The thing about autoconf is that after you've put all this effort into
    getting it to work right, the sense of satisfaction you get causes you
    to overlook the fact that you haven't actually tested it under other
    Unix variants. And in fact, your program still isn't portable.

    It's probably a product of the Sirius Cybernetics Corporation.

    --
    -Ed Falk,
    http://thespamdiaries.blogspot.com/
    Edward A. Falk, Jan 8, 2012
    #8
  9. ArifulHossain tuhin

    Dr Nick Guest

    Re: [OT] Bashing on autotools (Was: Building a sample application with libraries located in nonstandard directory)

    ec429 <> writes:

    > On 07/01/12 21:24, Seebs wrote:
    >> On 2012-01-07, Kaz Kylheku<> wrote:
    >>> Autoconf is a braindamaged pile of crap designed by imbeciles, but naive
    >>> developers keep trusting that it will take care of their build problems
    >>> somehow.

    >>
    >> This is unduly harsh. Autoconf is not nearly as stupid as it looks; it's just
    >> that 90% of the things it does which look stupid are only sensible if you
    >> assume that it matters whether stuff builds on Ultrix or SVR2. Which most of
    >> the stuff using it wouldn't anyway.
    >>
    >> (Not really C-related directly, but many C programmers get stuck trying to
    >> outsmart autoconf.)
    >>
    >> -s

    > Or you can write POSIX-compliant code, refuse to support
    > non-POSIX-compliant platforms, and chuck Autoconf in /dev/dustbin
    > where it belongs.


    Even then you need to do some of the things that Autoconf does - for
    example when different versions of libraries have a different interface.

    > Besides, even if you believe Autoconf's use case is valid, Autoconf is
    > not a well-designed solution to that problem; simply put, it's hairy.


    Agreed. But it's something that is likely to be there and that can do
    what you need doing (along with a lot of stuff you don't and never
    will).
    --
    Online waterways route planner | http://canalplan.eu
    Plan trips, see photos, check facilities | http://canalplan.org.uk
    Dr Nick, Jan 8, 2012
    #9
  10. Re: [OT] Bashing on autotools

    On 08.01.2012 10:15, Dr Nick wrote:
    > ec429 <> writes:
    >> Or you can write POSIX-compliant code, refuse to support
    >> non-POSIX-compliant platforms, and chuck Autoconf in /dev/dustbin
    >> where it belongs.

    >
    > Even then you need to do some of the things that Autoconf does - for
    > example when different versions of libraries have a different interface.
    >


    How about you build anyway and don't try to outsmart the administrator?
    If the library really has the wrong version, the build will fail. (If
    you just implement for one interface. If you implement for both you are
    doing double shift for nothing!)

    Just be nice and write it in your documentation somewhere!

    >> Besides, even if you believe Autoconf's use case is valid, Autoconf is
    >> not a well-designed solution to that problem; simply put, it's hairy.

    >
    > Agreed. But it's something that is likely to be there and that can do
    > what you need doing (along with a lot of stuff you don't and never
    > will).


    Yeah, that's the problem with FSF software: Featuritis. The program does
    what you want, and a ton of extra stuff.

    What's wrong with small posix compliant scripts in the build system,
    called by Makefiles?

    Ciao,
    Markus
    Markus Wichmann, Jan 8, 2012
    #10
  11. ArifulHossain tuhin

    Dr Nick Guest

    Re: [OT] Bashing on autotools

    Markus Wichmann <> writes:

    > On 08.01.2012 10:15, Dr Nick wrote:
    >> ec429 <> writes:
    >>> Or you can write POSIX-compliant code, refuse to support
    >>> non-POSIX-compliant platforms, and chuck Autoconf in /dev/dustbin
    >>> where it belongs.

    >>
    >> Even then you need to do some of the things that Autoconf does - for
    >> example when different versions of libraries have a different interface.
    >>

    >
    > How about you build anyway and don't try to outsmart the administrator?
    > If the library really has the wrong version, the build will fail. (If
    > you just implement for one interface. If you implement for both you are
    > doing double shift for nothing!)
    >
    > Just be nice and write it in your documentation somewhere!


    At one time I had something running on two machines, neither of which I
    had full control of, one of which was running the newer (at the time)
    version of Berkley DB which took an additional parameter to many of the
    functions.

    For the purposes I was using it, that extra parameter could happily be
    NULL, but it needed to be there.

    The code could easily be adapted to run fine under either version, but
    needed a small bit of conditional compilation to make it work under
    both.

    >>> Besides, even if you believe Autoconf's use case is valid, Autoconf is
    >>> not a well-designed solution to that problem; simply put, it's hairy.

    >>
    >> Agreed. But it's something that is likely to be there and that can do
    >> what you need doing (along with a lot of stuff you don't and never
    >> will).

    >
    > Yeah, that's the problem with FSF software: Featuritis. The program does
    > what you want, and a ton of extra stuff.
    >
    > What's wrong with small posix compliant scripts in the build system,
    > called by Makefiles?


    Nothing. But you have to write them and this can be more work than
    autoconf (just!).

    The question of when do I do it myself and when do I pull something
    bigger in and only use a bit of it isn't that clear cut. You can see
    just the same sort of thing with Javascript these days: do I hand-code
    each little bit I need or do I pull something like JQuery in?

    Because, obviously, the problem is that you end up hand coding so many
    little bits that it would have been easier to use someone else's, much
    bigger, solution in the first place.

    We're miles off C now, and not really that far apart I don't think.
    --
    Online waterways route planner | http://canalplan.eu
    Plan trips, see photos, check facilities | http://canalplan.org.uk
    Dr Nick, Jan 9, 2012
    #11
  12. Re: Building a sample application with libraries located innonstandard directory

    So you are suggesting avoiding configure scripts if i'm building a large project?

    What are the alternatives? Do you think hand made "makefiles" are more efficient way to approach?
    ArifulHossain tuhin, Jan 9, 2012
    #12
  13. Re: Building a sample application with libraries located in nonstandarddirectory

    On 09.01.2012 11:12, ArifulHossain tuhin wrote:
    > So you are suggesting avoiding configure scripts if i'm building a large project?
    >
    > What are the alternatives? Do you think hand made "makefiles" are more efficient way to approach?


    What do you need? Stuff like "compile all C files together into one big
    executable" goes like this:

    SRC:=$(wildcard *.c)
    OBJ:=$(SRC:.c=.o)

    executable: $(OBJ)
    cc -o $@ $^

    %.o: %.c
    cc -c -o $@ $<


    What's not to like? You may even append the output of "gcc -MM *.c" to
    that for more accuracy (which is usually only of interest during
    development)

    If you need subdirectories, you prepend:

    VPATH=subdir1:subdir2

    You will also probably need to have a config.h. I'd hand-craft a script
    to create it. That should be faster than autotools (because I don't
    check for fortran compilers).

    Also, you should avoid version tests, because at best they work for a
    relatively short period of time. Rather, you should check for the wanted
    features. Yes, that takes more time than a version check, but is more
    secure.

    I have yet to see a project make couldn't handle alone.

    Ciao,
    Markus
    Markus Wichmann, Jan 9, 2012
    #13
  14. ArifulHossain tuhin

    Seebs Guest

    Re: [OT] Bashing on autotools

    On 2012-01-08, Markus Wichmann <> wrote:
    > How about you build anyway and don't try to outsmart the administrator?
    > If the library really has the wrong version, the build will fail. (If
    > you just implement for one interface. If you implement for both you are
    > doing double shift for nothing!)


    If you don't implement for both, your code will run on only some systems. Those
    systems are large ecosystems with hundreds of packages, some of which may depend
    on the version of that interface already installed. Supporting both may be
    mandatory.

    > What's wrong with small posix compliant scripts in the build system,
    > called by Makefiles?


    Nothing intrinsically, but they don't come close to solving the problem
    autotools is trying to solve.

    -s
    --
    Copyright 2011, all wrongs reversed. Peter Seebach /
    http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
    http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
    I am not speaking for my employer, although they do rent some of my opinions.
    Seebs, Jan 9, 2012
    #14
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Kristoffer Arfvidson
    Replies:
    7
    Views:
    594
    Shiv Kumar
    Jan 21, 2004
  2. Mirek Fidler
    Replies:
    8
    Views:
    558
    Mirek Fidler
    Jul 3, 2003
  3. Hallvard B Furuseth

    Testing nonstandard assumption

    Hallvard B Furuseth, Jun 29, 2003, in forum: C Programming
    Replies:
    1
    Views:
    878
    Hallvard B Furuseth
    Jun 29, 2003
  4. Christian Seberino
    Replies:
    0
    Views:
    351
    Christian Seberino
    Oct 21, 2003
  5. Mark Hubbart
    Replies:
    5
    Views:
    258
    Patrick Bennett
    Oct 8, 2004
Loading...

Share This Page