On Sunday 13 January 2008 17:46, Ralf Wildenhues wrote:
* Richard Hacker wrote on Fri, Jan 11, 2008 at 01:21:50PM CET:
However, libtool is responsible for parsing *make's *FLAGS
Now, this contradicts your statement (*) above, no?
Oppps, my mistake. Sorry for confusing everyone :-(
No, as you
On Thursday 10 January 2008 21:30, Ralf Wildenhues wrote:
If you want all tools silenced which are called by make, then I suggest
to simply use
make /dev/null || make
well, we're after the automatic output going away, not intended output.
So what's intended output?
I think that
On Thursday 10 January 2008 08:29, Ralf Wildenhues wrote:
For whatever output is left done by libtool I expect that whoever want's
it silenced hard enough will have enough motivation to send a patch to
libtool-patches@gnu.org.
That shouldn't bee too difficult.
As a hint, make adds 's' to the
On Thursday 10 January 2008 08:29, Ralf Wildenhues wrote:
For whatever output is left done by libtool I expect that whoever want's
it silenced hard enough will have enough motivation to send a patch to
[EMAIL PROTECTED].
That shouldn't bee too difficult.
As a hint, make adds 's' to the
Hi Ralf,
On Wednesday 09 January 2008 07:48, Ralf Wildenhues wrote:
I think the issue is this: libtool doesn't add a run path to
/opt/etherlab/lib because it thinks the runtime linker will already
search that by default. Your --config output shows that it is listed
...
I'm wondering, if
Hi Ralf,
Attached are the two logs that you have requested. I hope this helps you
further. At least my assumption that libtool should get a library's path
information from libx.la is not wrong. ;)
Sorry for sending the logs unzipped previously.
Many thanks for your help.
- Richard
Hi all,
I'm experiencing some trouble using libtool inside the GNU autotools
collection. My compiled objects do not find their shared libraries that are
installed in non-standard library paths.
I wrote a C++ library, called rtcom for argument's sake, and used SWIG to make
it available as a
