Building a sample application with libraries located in nonstandard directory

[ArifulHossain tuhin]

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.

 

[ec429]

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

 

[Kenny McCormack]

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.
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?
-e

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

 

[Jens Thoms Toerring]

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

 

[Kaz Kylheku]

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.

 

[Seebs]

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

 

[ec429]

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

 

[Edward A. Falk]

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.

 

[Dr Nick]

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).

 

[Markus Wichmann]

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!

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

 

[Dr Nick]

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.

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.

 

[ArifulHossain tuhin]

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?

 

[Markus Wichmann]

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

 

[Seebs]

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