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
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 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 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
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 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:
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 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 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
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
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:
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:
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
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,
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
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
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
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
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
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/
20 matches
Mail list logo
