Tom,
Are you volunteering to convert the shell functions in CVS Libtool
into non-shell-function code? I would like to see this discussion
go in a different direction. I would like to see a list of the
platforms known to NOT have shell functions in their Bourne shells.
My point is that there are
Steve Ellcey <[EMAIL PROTECTED]> writes:
>
> Should I just tell the user to do two builds,
> with different options and different install directories?
For what it's worth, in GMP that's what we've done.
In principle there could be different libc functions and stuff in
different ABIs, so a fresh r
I have a general opensource packaging/build question that is sort of
related to libtool (I think) and was hoping someone could answer it
or provide me with a pointer.
For an opensource package that consists of one or more libraries and
that uses configure, automake, libtool, and the usual packagin
Hi,
When trying to build some apps, I got this :
[...]
checking dynamic linker characteristics... Linux ld.so
checking if libtool supports shared libraries... yes
*** Warning: the command libtool uses to detect shared libraries,
*** /usr/bin/file, produces output that libtool cannot recognize.
*
Jon Nall wrote:
why do .la files have to store hard-coded paths of the .so files they
reference? why aren't the names enough as ld.so should be able to query
it's cache of library directories at runtime?
why not? - in other words, what's your actual problem with it...
i realize libtool runs o
Today, Jon Nall wrote:
>
>why do .la files have to store hard-coded paths of the .so files they
>reference? why aren't the names enough as ld.so should be able to query
>it's cache of library directories at runtime?
>
>i realize libtool runs on lots of OSes, and maybe my question is
>linux-centric
why do .la files have to store hard-coded paths of the .so files they
reference? why aren't the names enough as ld.so should be able to query
it's cache of library directories at runtime?
i realize libtool runs on lots of OSes, and maybe my question is
linux-centric. but i really would like to un
