Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #15537 > unrolled thread

Building a sample application with libraries located in nonstandard directory

Back to article view | Back to comp.lang.c

Contents

  Building a sample application with libraries located in nonstandard directory ArifulHossain tuhin <etothepowerpi@gmail.com> - 2012-01-07 03:26 -0800
    Re: Building a sample application with libraries located in nonstandard directory ec429 <ec429@cam.ac.uk> - 2012-01-07 14:15 +0000
      Re: Building a sample application with libraries located in nonstandard directory gazelle@shell.xmission.com (Kenny McCormack) - 2012-01-07 16:26 +0000
      Re: Building a sample application with libraries located in nonstandard directory jt@toerring.de (Jens Thoms Toerring) - 2012-01-07 17:40 +0000
    Re: Building a sample application with libraries located in nonstandard directory Kaz Kylheku <kaz@kylheku.com> - 2012-01-07 17:50 +0000
      Re: Building a sample application with libraries located in nonstandard directory Seebs <usenet-nospam@seebs.net> - 2012-01-07 21:24 +0000
        [OT] Bashing on autotools (Was: Building a sample application with libraries located in nonstandard directory) ec429 <ec429@cam.ac.uk> - 2012-01-08 05:19 +0000
          Re: [OT] Bashing on autotools (Was: Building a sample application with libraries located in nonstandard directory) Dr Nick <3-nospam@temporary-address.org.uk> - 2012-01-08 09:15 +0000
            Re: [OT] Bashing on autotools Markus Wichmann <nullplan@gmx.net> - 2012-01-08 23:09 +0100
              Re: [OT] Bashing on autotools Dr Nick <3-nospam@temporary-address.org.uk> - 2012-01-09 07:53 +0000
              Re: [OT] Bashing on autotools Seebs <usenet-nospam@seebs.net> - 2012-01-09 19:21 +0000
      Re: Building a sample application with libraries located in nonstandard directory falk@rahul.net (Edward A. Falk) - 2012-01-08 07:13 +0000
      Re: Building a sample application with libraries located in nonstandard directory ArifulHossain tuhin <etothepowerpi@gmail.com> - 2012-01-09 02:12 -0800
        Re: Building a sample application with libraries located in nonstandard directory Markus Wichmann <nullplan@gmx.net> - 2012-01-09 15:00 +0100

#15537 — Building a sample application with libraries located in nonstandard directory

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.

[toc] | [next] | [standalone]

#15542

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

[toc] | [prev] | [next] | [standalone]

#15546

In article <je9k2a$ste$1@dont-email.me>, ec429  <ec429@cam.ac.uk> 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

[toc] | [prev] | [next] | [standalone]

#15548

ec429 <ec429@cam.ac.uk> 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  ___      jt@toerring.de
   \__________________________      http://toerring.de

[toc] | [prev] | [next] | [standalone]

#15549

On 2012-01-07, ArifulHossain tuhin <etothepowerpi@gmail.com> 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.

[toc] | [prev] | [next] | [standalone]

#15560

On 2012-01-07, Kaz Kylheku <kaz@kylheku.com> 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 / usenet-nospam@seebs.net
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.

[toc] | [prev] | [next] | [standalone]

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

On 07/01/12 21:24, Seebs wrote:
> On 2012-01-07, Kaz Kylheku<kaz@kylheku.com>  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

[toc] | [prev] | [next] | [standalone]

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

ec429 <ec429@cam.ac.uk> writes:

> On 07/01/12 21:24, Seebs wrote:
>> On 2012-01-07, Kaz Kylheku<kaz@kylheku.com>  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

[toc] | [prev] | [next] | [standalone]

#15607 — Re: [OT] Bashing on autotools

On 08.01.2012 10:15, Dr Nick wrote:
> ec429 <ec429@cam.ac.uk> 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

[toc] | [prev] | [next] | [standalone]

#15608 — Re: [OT] Bashing on autotools

Markus Wichmann <nullplan@gmx.net> writes:

> On 08.01.2012 10:15, Dr Nick wrote:
>> ec429 <ec429@cam.ac.uk> 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

[toc] | [prev] | [next] | [standalone]

#15655 — Re: [OT] Bashing on autotools

On 2012-01-08, Markus Wichmann <nullplan@gmx.net> 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 / usenet-nospam@seebs.net
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.

[toc] | [prev] | [next] | [standalone]

#15567

In article <20120107093130.782@kylheku.com>,
Kaz Kylheku  <kaz@kylheku.com> 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, falk@despams.r.us.com
	http://thespamdiaries.blogspot.com/

[toc] | [prev] | [next] | [standalone]

#15610

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?

[toc] | [prev] | [next] | [standalone]

#15641

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.c

csiph-web