help-make
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: VPATH/vpath: does it work for -l<libname> prereqs?


From: Maxim Nikulin
Subject: Re: VPATH/vpath: does it work for -l<libname> prereqs?
Date: Thu, 24 Nov 2005 01:09:11 +0600
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050513 Debian/1.7.8-1

Hi,

I have got several problems with -l prerequisites too. In the beginning
I thought it's a greet feature, but than I almost threw it away. I'll be
glad to hear that I missed something. The possibility to choose static
or dynamic libraries is rather attractive.

1. Let's imagine I have rules to build a library libfoo.so and link a
program bar with this library in the same makefile. Everything works
fine if I place libfoo.so in a subdirectory:

$ ls . foo/
.:
foo  Makefile

foo/:
$ cat Makefile
bar: -lfoo
        touch $@
foo/libfoo.so:
        touch $@
vpath lib%.so foo
$ make
touch foo/libfoo.so
touch bar

The problem is that I can't build the library in the same directory:

$ ls
Makefile
$ cat Makefile
bar: -lfoo
        touch $@
libfoo.so:
        touch $@
$ make
make: *** No rule to make target `-lfoo', needed by `bar'.  Stop.

2. The second example requires a real program and a shared library in a
subdirectory

$ cat foo/foo.c
int foo()
{
   return 1;
}
$ cat bar.c
int foo();
int main()
{
   int a = foo();
   return 0;
}
$ cat Makefile
all: bar
bar: -lfoo
foo/libfoo.so: foo/foo.c
        $(CC) -shared -o $@ $^
vpath lib%.so foo
$ make
cc -shared -o foo/libfoo.so foo/foo.c
cc     bar.c foo/libfoo.so   -o bar

Make builds the program, but information for dynamic loader is incorrect

$ ldd bar
                foo/libfoo.so => foo/libfoo.so (0x40018000)
        libc.so.6 => /lib/tls/libc.so.6 (0x40032000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

I don't like the line 'foo/libfoo.so => foo/libfoo.so'. If the library
passed to linker as -lfoo, the result is different:

$ cc bar.c -Lfoo -lfoo -o bar
$ ldd bar
                libfoo.so => not found
        libc.so.6 => /lib/tls/libc.so.6 (0x40030000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

In this case loader looks for libfoo.so, not for foo/libfoo.so, thus I
can just put path to libfoo.so in LD_LIBRARY_PATH. It's possible to add
-Wl,-soname,libfoo.so to the library building rule. Well, I can do this
in my makefiles, but it's not so easy to force other people modify their
rules.

3. Let's consider deep complicated recursive build (I wouldn't argue
about non-recursive approach and its advantages). Every package install
headers and libraries into intermediate directories so they are
available for other packages. I tried to speed up rebuilding by
minimizing of copy operations. The aim is not to copy a file in the
intermediate directory if it's not outdated. The rule

/intermediate/dir/libfoo.so: libfoo.so
        $(INSTALL) $< $@

leads to complains on circular dependence if /intermediate/dir is in vpath.

I've found work-around for all three cases, but I appreciate suggestions
concerning the cases 1 and 2. I still believe that the idea of -l
prerequisites is elegant.

--
Maxim Nikulin





reply via email to

[Prev in Thread] Current Thread [Next in Thread]