Hello,
I link 3 libraries with libtool. The first one is linked with hdf lib that
is in system (/usr/lib), the
second one is linked with vtk lib that is not in system ($VTKHOME) and the
third one is linked
with the 2 previous libs.
The problem is that there is another vtlk lib in system (/usr/
Salut Christian,
On 9 Jun 2010, at 14:41, Christian CAREMOLI wrote:
> Hello,
>
> I link 3 libraries with libtool. The first one is linked with hdf lib that is
> in system (/usr/lib), the
> second one is linked with vtk lib that is not in system ($VTKHOME) and the
> third one is linked
> with
Hi Christian,
On 9 Jun 2010, at 01:43, Christian Rössel wrote:
> Am 6/4/2010 1:44 PM, schrieb Gary V. Vaughan:
>
>> * Changes in supported systems or compilers:
>>
>> - Improved support for 64bit Windows (mingw64).
>> - Improved support for cegcc (Windows CE/PocketPC).
>> - Support for GNU/kO
Den 2010-06-08 18:19 skrev Christopher Hulbert:
On Tue, Jun 8, 2010 at 11:03 AM, Peter Rosin wrote:
Den 2010-06-08 15:40 skrev Christopher Hulbert:
On Tue, Jun 8, 2010 at 9:24 AM, Peter Rosinwrote:
I've had enough frustration here, methinks.
Sorry for my contribution to your frustrati
Hello Gary
I resend my question from gmail.
Most likely your libhdf.la has -L/usr/libs in its dependency_libs entry.
> You can fix that by editing the libhdf.la file to pass the library name by
> its full path, or by adjusting the install process of libhdf not to record
> -L/usr/libs there.
>
de
Hi Christian,
On 9 Jun 2010, at 19:27, christian caremoli wrote:
> I resend my question from gmail.
Thanks :)
> Most likely your libhdf.la has -L/usr/libs in its dependency_libs entry. You
> can fix that by editing the libhdf.la file to pass the library name by its
> full path, or by adjustin
Hi Peter,
[[Adding libtool list]]
On 9 Jun 2010, at 20:21, Peter Rosin wrote:
> Den 2010-06-09 14:50 skrev Gary V. Vaughan:
>> [[...]] we can begin to evaluate whether to use pr-support-msvc-branch
>> in 2.2.12, or wait for 2.4.0.
>
> I don't really care how the merge happens as long as somethin
Hi Christian,
[[Libtool list added back in to Cc:]]
On 9 Jun 2010, at 21:17, christian caremoli wrote:
> 2010/6/9 Gary V. Vaughan
> > Most likely your libhdf.la has -L/usr/libs in its dependency_libs entry.
> > You can fix that by editing the libhdf.la file to pass the library name by
> > its
Libtoolers!
GNU Libtool hides the complexity of using shared libraries behind a
consistent, portable interface. GNU Libtool ships with GNU libltdl, which
hides the complexity of loading dynamic runtime libraries (modules) behind
a consistent, portable interface.
Here are the compressed sources:
how can I get the value of export_dynamic_flag_spec substituted by configure?
I have this in my configure.in:
AC_LIBTOOL_DLOPEN_SELF dnl do I even need this?!
AC_PROG_LIBTOOL
EXPORT_DYNAMIC_FLAG_SPEC=$export_dynamic_flag_spec
AC_SUBST(EXPORT_DYNAMIC_FLAG_SPEC)dnl
and this in my foo.sh.in file:
On Wed, 9 Jun 2010, Gary V. Vaughan wrote:
M4 master, for example, has had to simply turn off all the
libltdl/OS run-time loader path searching to maintain any cross
platform sanity (it does this by managing it's own search path
environment variable, making the searches itself and then always
Hi Sam,
On 10 Jun 2010, at 01:51, Sam Steingold wrote:
> how can I get the value of export_dynamic_flag_spec substituted by configure?
> I have this in my configure.in:
>
> AC_LIBTOOL_DLOPEN_SELF dnl do I even need this?!
> AC_PROG_LIBTOOL
> EXPORT_DYNAMIC_FLAG_SPEC=$export_dynamic_flag_spec
> AC
Hi Sam,
On 10 Jun 2010, at 02:35, Sam Steingold wrote:
> On 6/9/10, Gary V. Vaughan wrote:
>> On 10 Jun 2010, at 01:51, Sam Steingold wrote:
>>> EXPORT_DYNAMIC_FLAG_SPEC='@EXPORT_DYNAMIC_FLAG_SPEC@'
>>>
>>> alas, instead of
>>>
>>> EXPORT_DYNAMIC_FLAG_SPEC='-Wl,--export-dynamic'
>>>
>>> foo.sh
Hi Christian,
[[Libtool list added back in to Cc:]]
Please don't top post on technical lists, but thanks for not sending the long
logs to the list :)
On 9 Jun 2010, at 23:10, christian caremoli wrote:
> 2010/6/9 Gary V. Vaughan
> Hi Christian,
>
> [[Libtool list added back in to Cc:]]
>
> On
Hi Gary,
thanks for your kind reply.
On 6/9/10, Gary V. Vaughan wrote:
> On 10 Jun 2010, at 01:51, Sam Steingold wrote:
> > EXPORT_DYNAMIC_FLAG_SPEC='@EXPORT_DYNAMIC_FLAG_SPEC@'
> >
> > alas, instead of
> >
> > EXPORT_DYNAMIC_FLAG_SPEC='-Wl,--export-dynamic'
> >
> > foo.sh contains this:
On 06/09/2010 04:46 PM, Gary V. Vaughan wrote:
Why so much cruft in ltmain.m4sh just to drive a different archiver? It
seems to me that this would be better and easier to maintain, test and extend
as a whole new script. Let's call it, $prefix/libexec/libtool/ar, build it
from $srcdir/libltdl/co
Hi Paolo,
On 10 Jun 2010, at 08:18, Paolo Bonzini wrote:
> On 06/09/2010 04:46 PM, Gary V. Vaughan wrote:
>> Why so much cruft in ltmain.m4sh just to drive a different archiver? It
>> seems to me that this would be better and easier to maintain, test and extend
>> as a whole new script. Let's c
Hi Paolo,
On 10 Jun 2010, at 11:07, Gary V. Vaughan wrote:
> On 10 Jun 2010, at 08:18, Paolo Bonzini wrote:
>> On 06/09/2010 04:46 PM, Gary V. Vaughan wrote:
>>> Why so much cruft in ltmain.m4sh just to drive a different archiver? It
>>> seems to me that this would be better and easier to maintai
Hi,
As I am sure many are aware, libltdl's error reporting is pretty dumb,
lt_dlerror() regularly reports things like "file not found" where the
actual problem might be something completely different, and a reasonable
error string may be readily available from dlerror().
When I looked at the
Hi Peter,
On 10 Jun 2010, at 12:33, Peter O'Gorman wrote:
> As I am sure many are aware, libltdl's error reporting is pretty dumb,
> lt_dlerror() regularly reports things like "file not found" where the actual
> problem might be something completely different, and a reasonable error
> string ma
20 matches
Mail list logo
