Markus Duft wrote:
Hi
I'm working (together with haubi) on getting DESTDIR support for our
hppa-hpux boxes into libtool. I now have it working, and a first
patch
(which of course breaks some other things - I know that :( ), and
wanted to
ask what you think about this.
I'm
Duft Markus wrote:
But anyway, for me right now small side effects or very special
special-cases would not matter that much. It would be much more
important to get DESTDIR to work. However it would still be more than
cool to get DESTDIR support in upstream libtool, without having to apply
Peter Rosin wrote:
[snip]
Again, I just /mentioned/ the patchlevel issue. I'm only advocating
that
the API level of the ms runtime be encoded in $host. (Anything finer
grained is just as completely FUBARed^W difficult to manage as MS's
side-by-side solution).
So then id' suggest the
Duft Markus wrote:
But anyway, for me right now small side effects or very special
special-cases would not matter that much. It would be much more
important to get DESTDIR to work. However it would still be more
than
cool to get DESTDIR support in upstream libtool, without
Duft Markus wrote:
Patches that do more good than harm are likely to be accepted.
That's exactly the point i'm unsure about, if I do more harm than good
or the other way round :) of course, for _me_ I do more good, but does
it harm others that the hardcode test fails now?
Sorry, don't know
Peter Rosin skrev:
I created a simple dll, exporting one function doing a printf (some random
libc function). When building this dll, MSVC8 generated a manifest, but I
instead embedded the manifest pointing to an older msvcr80.
I.e. Embedded this:
assemblyIdentity type='win32'
Duft Markus wrote:
Patches that do more good than harm are likely to be accepted.
That's exactly the point i'm unsure about, if I do more harm than
good
or the other way round :) of course, for _me_ I do more good, but
does
it harm others that the hardcode test fails now?
Sorry,
Hi Peter,
* Peter O'Gorman wrote on Sat, Aug 23, 2008 at 11:59:00PM CEST:
On systems without argz we were exporting unmangled symbols argz_count
and argz_add from libltdl. Not really a good idea. Rather than mangle
the names, since we do not use either function, they were removed.
Subject:
Hi Peter,
* Peter O'Gorman wrote on Sat, Aug 23, 2008 at 11:59:00PM CEST:
Subject: [PATCH] Allow for extensions other than .a for preloaded modules.
* libltdl/m4/ltdl.m4 (_LTDL_SETUP): Define LT_LIBEXT.
* libltdl/ltdl.c (lt_dladvise_preload): Use it.
Reported by Ralf Wildenhues.
OK,
Charles Wilson skrev:
I also think that -winnt is too broad; and I'd really hate to see the
massive uglification of the libtool code -- and thousands of
configure.ac's out there -- that would ensue if -mingw* were
/officially/ overloaded to also represent the msvc-toolchain case.
Thanks a
Ralf Wildenhues wrote:
Yes, certainly. I think a NEWS entry would be good, too, as well as
a test so we don't regress again. What do you think of this? You
can squash it into your patch when you commit.
Thanks.
The test doesn't work on many systems (only those that need argz.c,
and
* Peter O'Gorman wrote on Tue, Aug 26, 2008 at 06:24:11PM CEST:
Ralf Wildenhues wrote:
I'd like this to fail for me on darwin (more likely to notice it), so I
will probably add:
+AT_CHECK([eval $NM \\$argz_o\ | $global_symbol_pipe],
+[], [stdout], [ignore])
+AT_CHECK([grep ^T
12 matches
Mail list logo
