Re: solaris link line length problem == buggy sed
On Wednesday 18 July 2001 12:33 am, Robert Boehne wrote:
> Alex Hornby wrote:
> > My earlier link line truncation problem on solaris was not due to
> > command line length restrictions (getconf reports a healthy 109kb for
> > ARG_MAX).
> >
> > Solaris 2.6 /usr/bin/sed, as used by libtool during the link, has
> > problems with "long" lines of > 3999 characters, truncating them as it
> > sees fit.
> >
> > By putting GNU sed ahead of solaris sed on my PATH the build succeeds.
> >
> > Should libtool work around such broken sed's during the build phase,
> > and would patches be considered that did this?
> >
> > Regards,
> > Alex.
>
> Ok, I'm trying to write a macro for libtool.m4 that will check for
> bugs such as this one in sed. However, if I create a file inline
> with 8202 characters on one line, Linux bash segfaults!
> It does work under IRIX and Solaris, so my approach seems OK.
> Here is what it basically does:
>
> cat > conftest.$ac_ext < XX
> EOF
> sed 's/Y/Z/g' conftest.$ac_ext > conftest.out
> lt_cv_buggy_sed="yes"
> cmp conftest.$ac_ext conftest.out >/dev/null && lt_cv_buggy_sed="no"
> 2>&1
> ls -al conftest.$ac_ext conftest.out
> cat conftest.$ac_ext
> fi
>
> Since bash 1.14.7 under Linux (Redhat 6.2) seems to have a
> problem with such a long inline file, is there a way to
> concatenate a character or characters into a file without
> adding newlines?
The easiest way to do it without tripping over echo non-portabilities is:
echo | tr '\010' X >> file
Ofcourse tr has some issues of its own, so you might prefer:
echo | awk '{ printf "X"; }' >> file
But then you have to find a suitable awk binary in your PATH, so maybe
testing which of the following leaves no droppings and use that:
echo -n X
echo 'X\c'
echo -e 'X\c'
Which takes us back to the start. Go round a few times, and get off at your
favourite stop =)O|
> Granted, I can simply skip this if GNU sed is found, but
> I'm sure it will come up again on some other sed/shell
> combination.
This is really an autoconf macro, since it has applicability beyond what
libtool needs...
Cheers,
Gary.
--
())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org)
( '/ Research Scientist http://www.oranda.demon.co.uk ,_())
/ )= GNU Hacker http://www.gnu.org/software/libtool \' `&
`(_~)_ Tech' Authorhttp://sources.redhat.com/autobook =`---d__/
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: solaris link line length problem == buggy sed
Alex Hornby wrote: > > My earlier link line truncation problem on solaris was not due to > command line length restrictions (getconf reports a healthy 109kb for > ARG_MAX). > > Solaris 2.6 /usr/bin/sed, as used by libtool during the link, has > problems with "long" lines of > 3999 characters, truncating them as it > sees fit. > > By putting GNU sed ahead of solaris sed on my PATH the build succeeds. > > Should libtool work around such broken sed's during the build phase, > and would patches be considered that did this? > > Regards, > Alex. > Ok, I'm trying to write a macro for libtool.m4 that will check for bugs such as this one in sed. However, if I create a file inline with 8202 characters on one line, Linux bash segfaults! It does work under IRIX and Solaris, so my approach seems OK. Here is what it basically does: cat > conftest.$ac_ext < EOF sed 's/Y/Z/g' conftest.$ac_ext > conftest.out lt_cv_buggy_sed="yes" cmp conftest.$ac_ext conftest.out >/dev/null && lt_cv_buggy_sed="no" 2>&1 ls -al conftest.$ac_ext conftest.out cat conftest.$ac_ext fi Since bash 1.14.7 under Linux (Redhat 6.2) seems to have a problem with such a long inline file, is there a way to concatenate a character or characters into a file without adding newlines? Granted, I can simply skip this if GNU sed is found, but I'm sure it will come up again on some other sed/shell combination. Robert -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: make check failures
On Tuesday 17 July 2001 12:00 pm, Patrick Welche wrote:
> A quick look says that in ltdl.c, presym_open() if you get there with a
> call to lt_dlopen(0), filename is null, so
>
> if (!filename)
> {
> filename = "@PROGRAM@";
> }
>
> then later:
>
> if (!syms->address && strcmp(syms->name, filename) == 0)
>
> as address==0, we look for syms->name == "@PROGRAM@", but name is things
> like "libfoo2_LTX_nothing" or "libsub.a".. Unless the problem is that
> @PROGRAM@ should get substituted? (All I did was run mdemo.static with no
> arguments)
Nup. What you describe is perfectly normal. As the table of preloaded
symbols is built, each module that provides some symbols is also listed in
lt_preloaded_symbols[], with the address field set to `(lt_ptr) 0', and the
name field set to the name of the module. Strictly speaking for lt_dlopen(0)
to work we would do the same, except that the marker for the end of the table
is NULL in both fields, so we chose an unlikely module name to mark the start
of the symbols extracted from the program itself -- @PROGRAM@.
> (BTW I just came across ltdl.c:1783 LT_DLFREE (canonical), canonical=6(!) )
Huh? As far as I can tell by code inspection that can only happen if the
user_search_path is set to 6... clearly, something is very wrong...
> I suppose the main question is: Is it just me?
Not necessarily. Though no-one else has complained of problems on NetBSD.
Let me know if you get to the bottom of this.
Cheers,
Gary.
--
())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org)
( '/ Research Scientist http://www.oranda.demon.co.uk ,_())
/ )= GNU Hacker http://www.gnu.org/software/libtool \' `&
`(_~)_ Tech' Authorhttp://sources.redhat.com/autobook =`---d__/
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS
On Tue, Jul 17, 2001 at 12:33:28PM -0500, Robert Boehne wrote: > From earlier discussions, it was noted that > libltdl_cv_sys_dlopen_deplibs=yes > actually not only referrs to dlopen() calls, but their equivalents > on other OS's like HPUX. Why don't we do this: set > ibltdl_cv_sys_dlopen_deplibs > based on host in configury, then add a test case that uses libltdl to > check if libltdl_cv_sys_dlopen_deplibs is set properly? > That way those platforms that aren't set properly will fail the test > case, and we will be notified we need to change ltdl.m4 to fix it. > This doesn't handle the cases such as Tru64 5.1 patched vs not patched > but it gets us most of the way there. N'cest pas? Actually, why not set libltdl_cv_sys_dlopen_deplibs=yes regardless of host configury and then if ltdl cannot load the library, set libltdl_cv_sys_dlopen_deplibs=unknown? I thought about this but, having not looked too much into ltdl, don't know how difficult it would be. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS
On Tuesday 17 July 2001 4:10 pm, Robert Boehne wrote: > "Gary V. Vaughan" wrote: > > On Monday 16 July 2001 4:10 pm, Robert Boehne wrote: > > > Here is the test case, if someone wants to libtoolize it, we > > > could add it to the macro. > > > > Seconded! I would happily accept a patch to perform the test *instead* > > of listing values for only hosts triplets that have been researched... > > If we use the test *instead* of looking at the host we would miss the > case for Tru64 4-5.1, which passes the test but doesn't search the > library RPATH, but perhaps we could limit it to that case only. I didn't look at the test tarball you posted yet, but it should be (relatively speaking) easy to set the rpath as a library is being build and place an essential deplib in the rpath, while setting LD_LIBRARY_PATH et. al. to point elsewhere. Cheers, Gary. -- ())_. Gary V. Vaughan gary@(oranda.demon.co.uk|gnu.org) ( '/ Research Scientist http://www.oranda.demon.co.uk ,_()) / )= GNU Hacker http://www.gnu.org/software/libtool \' `& `(_~)_ Tech' Authorhttp://sources.redhat.com/autobook =`---d__/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS
Albert:
>From earlier discussions, it was noted that
libltdl_cv_sys_dlopen_deplibs=yes
actually not only referrs to dlopen() calls, but their equivalents
on other OS's like HPUX. Why don't we do this: set
ibltdl_cv_sys_dlopen_deplibs
based on host in configury, then add a test case that uses libltdl to
check if libltdl_cv_sys_dlopen_deplibs is set properly?
That way those platforms that aren't set properly will fail the test
case, and we will be notified we need to change ltdl.m4 to fix it.
This doesn't handle the cases such as Tru64 5.1 patched vs not patched
but it gets us most of the way there. N'cest pas?
Robert
[EMAIL PROTECTED] wrote:
>
> On Tue, Jul 17, 2001 at 11:36:11AM -0500, Robert Boehne wrote:
> > [EMAIL PROTECTED] wrote:
> > >
> > > On Tue, Jul 17, 2001 at 10:10:49AM -0500, Robert Boehne wrote:
> > > > "Gary V. Vaughan" wrote:
> > > > >
> > > > > On Monday 16 July 2001 4:10 pm, Robert Boehne wrote:
> > > > > > Here is the test case, if someone wants to libtoolize it, we
> > > > > > could add it to the macro.
> > > > >
> > > > > Seconded! I would happily accept a patch to perform the test *instead* of
> > > > > listing values for only hosts triplets that have been researched...
> > > > >
> > > > > Cheers,
> > > > > Gary.
> > > >
> > > > If we use the test *instead* of looking at the host we would miss the
> > > > case for Tru64 4-5.1, which passes the test but doesn't search the
> > > > library RPATH, but perhaps we could limit it to that case only.
> > >
> > > Then how about augmenting the patch to catch this case? This is
> > > actually important for people how have Tru64 UNIX with patch kit < #2
> > > where such an augmented test would fail and patch kit >= #2 where the
> > > augmented test should succeed.
> > >
> > > --
> > > albert chin ([EMAIL PROTECTED])
> >
> > That's a great idea, if we don't want to set dlopen_deplibs to "yes"
> > in that case anyway that is what we should test for.
> > I'm having some trouble creating this test case though, how can
> > I use ltdl in a program that is used to create libtool?
>
> Just so I'm on the same page, this is to autodetect
> $libltdl_cv_sys_dlopen_deplibs correct? If so, why do you want to use
> ltdl at all? Isn't it enough to write the following test programs
> during the run of ltdl.m4:
> ('t1') dlopen test program 't2'
> ('t2') dlopen'ed by 't1' and depends on library 't3'
> ('t3') library depending on 't4'
> ('t4') dummy library
> and then run t1. If you fail, libltdl_cv_sys_dlopen_deplibs=unknown.
> If you succeed, libltdl_cv_sys_dlopen_deplibs=yes.
>
> The purpose of 't2' is to detect if dlopen loads dependency libraries
> and the purpose of 't3' is to detect if dlopen honours RPATH in a
> library.
>
> BTW, this probably isn't so trivial because you'd need to embed the
> runtime path into programs 't2' and 't3'. You definitely don't want to
> set LD_LIBRARY_PATH. Can you use the generated libtool program during
> ltdl.m4?
>
> --
> albert chin ([EMAIL PROTECTED])
>
> ___
> Libtool mailing list
> [EMAIL PROTECTED]
> http://mail.gnu.org/mailman/listinfo/libtool
--
Robert Boehne Software Engineer
Ricardo Software Chicago Technical Center
TEL: (630)789-0003 x. 238
FAX: (630)789-0127
email: [EMAIL PROTECTED]
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS
On Tue, Jul 17, 2001 at 11:36:11AM -0500, Robert Boehne wrote:
> [EMAIL PROTECTED] wrote:
> >
> > On Tue, Jul 17, 2001 at 10:10:49AM -0500, Robert Boehne wrote:
> > > "Gary V. Vaughan" wrote:
> > > >
> > > > On Monday 16 July 2001 4:10 pm, Robert Boehne wrote:
> > > > > Here is the test case, if someone wants to libtoolize it, we
> > > > > could add it to the macro.
> > > >
> > > > Seconded! I would happily accept a patch to perform the test *instead* of
> > > > listing values for only hosts triplets that have been researched...
> > > >
> > > > Cheers,
> > > > Gary.
> > >
> > > If we use the test *instead* of looking at the host we would miss the
> > > case for Tru64 4-5.1, which passes the test but doesn't search the
> > > library RPATH, but perhaps we could limit it to that case only.
> >
> > Then how about augmenting the patch to catch this case? This is
> > actually important for people how have Tru64 UNIX with patch kit < #2
> > where such an augmented test would fail and patch kit >= #2 where the
> > augmented test should succeed.
> >
> > --
> > albert chin ([EMAIL PROTECTED])
>
> That's a great idea, if we don't want to set dlopen_deplibs to "yes"
> in that case anyway that is what we should test for.
> I'm having some trouble creating this test case though, how can
> I use ltdl in a program that is used to create libtool?
Just so I'm on the same page, this is to autodetect
$libltdl_cv_sys_dlopen_deplibs correct? If so, why do you want to use
ltdl at all? Isn't it enough to write the following test programs
during the run of ltdl.m4:
('t1') dlopen test program 't2'
('t2') dlopen'ed by 't1' and depends on library 't3'
('t3') library depending on 't4'
('t4') dummy library
and then run t1. If you fail, libltdl_cv_sys_dlopen_deplibs=unknown.
If you succeed, libltdl_cv_sys_dlopen_deplibs=yes.
The purpose of 't2' is to detect if dlopen loads dependency libraries
and the purpose of 't3' is to detect if dlopen honours RPATH in a
library.
BTW, this probably isn't so trivial because you'd need to embed the
runtime path into programs 't2' and 't3'. You definitely don't want to
set LD_LIBRARY_PATH. Can you use the generated libtool program during
ltdl.m4?
--
albert chin ([EMAIL PROTECTED])
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS
Tim: Looks good, I'm going to commit this now as it seems that writing a test is not quite trivial (to me at least ;). Robert Tim Mooney wrote: > > In regard to: Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS, Gary V: > > >On Monday 16 July 2001 4:10 pm, Robert Boehne wrote: > >> Here is the test case, if someone wants to libtoolize it, we > >> could add it to the macro. > > > >Seconded! I would happily accept a patch to perform the test *instead* of > >listing values for only hosts triplets that have been researched... > > :-) For now, what do you think of the updated patch, below? > > Tim > -- > Tim Mooney [EMAIL PROTECTED] > Information Technology Services (701) 231-1076 (Voice) > Room 242-J6, IACC Building (701) 231-8541 (Fax) > North Dakota State University, Fargo, ND 58105-5164 > > diff -ur libtool-1.4b.orig/ltdl.m4 libtool-1.4b/ltdl.m4 > --- libtool-1.4b.orig/ltdl.m4 Thu Jul 5 18:10:26 2001 > +++ libtool-1.4b/ltdl.m4Mon Jul 16 16:06:34 2001 > @@ -70,13 +70,57 @@ > [AC_REQUIRE([AC_CANONICAL_HOST]) > AC_CACHE_CHECK([whether deplibs are loaded by dlopen], > libltdl_cv_sys_dlopen_deplibs, [dnl > - # PORTME does your system automatically load deplibs for dlopen()? > + # PORTME does your system automatically load deplibs for dlopen() > + # or its logical equivalent (e.g. shl_load for HP-UX < 11) > + # For now, we just catch OSes we know something about -- in the > + # future, we'll try test this programmatically. > libltdl_cv_sys_dlopen_deplibs=unknown > case "$host_os" in > + aix3*|aix4.1.*|aix4.2.*) > + # Unknown whether this is true for these versions of AIX, but > + # we want this `case' here to explicitly catch those versions. > + libltdl_cv_sys_dlopen_deplibs=unknown > + ;; > + aix4*) > + # Unknown whether this is true for aix5, but is true for aix >= 4.3.* > + libltdl_cv_sys_dlopen_deplibs=yes > + ;; > + irix[12345]*|irix6.[01234]*) > + # Catch all versions of IRIX before 6.5, and indicate that we don't > + # know how it worked for any of those versions. > + libltdl_cv_sys_dlopen_deplibs=unknown > + ;; > + irix*) > + # The case above catches anything before 6.5, and it's known that > + # at 6.5 and later dlopen does load deplibs. > + libltdl_cv_sys_dlopen_deplibs=yes > + ;; > linux*) > libltdl_cv_sys_dlopen_deplibs=yes > ;; > netbsd*) > + libltdl_cv_sys_dlopen_deplibs=yes > + ;; > + osf[1234]*) > + # dlopen did load deplibs (at least at 4.x), but until the 5.x series, > + # it did *not* use an RPATH in a shared library to find objects the > + # library depends on, so we explictly say `no'. > + libltdl_cv_sys_dlopen_deplibs=no > + ;; > + osf5.0|osf5.0a|osf5.1) > + # dlopen *does* load deplibs and with the right loader patch applied > + # it even uses RPATH in a shared library to search for shared objects > + # that the library depends on, but there's no easy way to know if that > + # patch is installed. Since this is the case, all we can really > + # say is unknown -- it depends on the patch being installed. If > + # it is, this changes to `yes'. Without it, it would be `no'. > + libltdl_cv_sys_dlopen_deplibs=unknown > + ;; > + osf*) > + # the two cases above should catch all versions of osf <= 5.1. Read > + # the comments above for what we know about them. > + # At > 5.1, deplibs are loaded *and* any RPATH in a shared library > + # is used to find them so we can finally say `yes'. > libltdl_cv_sys_dlopen_deplibs=yes > ;; > solaris*) > --- libtool-1.4b.orig/ChangeLog Mon Jul 9 17:02:09 2001 > +++ libtool-1.4b/ChangeLog Mon Jul 16 16:10:41 2001 > @@ -0,0 +1,5 @@ > +2001-07-16 Robert Boehne <[EMAIL PROTECTED]>, Tim Mooney ><[EMAIL PROTECTED]> > + > + * ltdl.m4 (AC_LTDL_SYS_DLOPEN_DEPLIBS): add cases and comments for > + more platforms, including AIX, Digital/Tru64 UNIX and IRIX. > + -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS
[EMAIL PROTECTED] wrote: > > On Tue, Jul 17, 2001 at 10:10:49AM -0500, Robert Boehne wrote: > > "Gary V. Vaughan" wrote: > > > > > > On Monday 16 July 2001 4:10 pm, Robert Boehne wrote: > > > > Here is the test case, if someone wants to libtoolize it, we > > > > could add it to the macro. > > > > > > Seconded! I would happily accept a patch to perform the test *instead* of > > > listing values for only hosts triplets that have been researched... > > > > > > Cheers, > > > Gary. > > > > If we use the test *instead* of looking at the host we would miss the > > case for Tru64 4-5.1, which passes the test but doesn't search the > > library RPATH, but perhaps we could limit it to that case only. > > Then how about augmenting the patch to catch this case? This is > actually important for people how have Tru64 UNIX with patch kit < #2 > where such an augmented test would fail and patch kit >= #2 where the > augmented test should succeed. > > -- > albert chin ([EMAIL PROTECTED]) Albert: That's a great idea, if we don't want to set dlopen_deplibs to "yes" in that case anyway that is what we should test for. I'm having some trouble creating this test case though, how can I use ltdl in a program that is used to create libtool? Robert -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS
On Tue, Jul 17, 2001 at 10:10:49AM -0500, Robert Boehne wrote: > "Gary V. Vaughan" wrote: > > > > On Monday 16 July 2001 4:10 pm, Robert Boehne wrote: > > > Here is the test case, if someone wants to libtoolize it, we > > > could add it to the macro. > > > > Seconded! I would happily accept a patch to perform the test *instead* of > > listing values for only hosts triplets that have been researched... > > > > Cheers, > > Gary. > > If we use the test *instead* of looking at the host we would miss the > case for Tru64 4-5.1, which passes the test but doesn't search the > library RPATH, but perhaps we could limit it to that case only. Then how about augmenting the patch to catch this case? This is actually important for people how have Tru64 UNIX with patch kit < #2 where such an augmented test would fail and patch kit >= #2 where the augmented test should succeed. -- albert chin ([EMAIL PROTECTED]) ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: question about AC_LTDL_SYS_DLOPEN_DEPLIBS
"Gary V. Vaughan" wrote: > > On Monday 16 July 2001 4:10 pm, Robert Boehne wrote: > > Here is the test case, if someone wants to libtoolize it, we > > could add it to the macro. > > Seconded! I would happily accept a patch to perform the test *instead* of > listing values for only hosts triplets that have been researched... > > Cheers, > Gary. Gary: If we use the test *instead* of looking at the host we would miss the case for Tru64 4-5.1, which passes the test but doesn't search the library RPATH, but perhaps we could limit it to that case only. Robert -- Robert Boehne Software Engineer Ricardo Software Chicago Technical Center TEL: (630)789-0003 x. 238 FAX: (630)789-0127 email: [EMAIL PROTECTED] ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: Overriding startfiles and C library with libtool libraries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Thanks all for your hints/comments. (John Reiser was in first with 'use the specs, Luke'). I'm rapidly coming to the conclusion that libtool isn't capable of doing quite what I want it to, and libtool 1.3.5's ltmain.sh is so convoluted, I'm not going to attempt to patch it support this (what I effectively need is to override the specs at *compile-time*, but not at install-time when the library/program is rebuilt). As this only affects one particular platform, I'm going to write a drop-in libtool replacement specifically for this,along with appropriate autoconfery to use it if the platform is supported by it, and disable the kernel and C library build if it is not. This seems to me to be the easiest route (writing a platform-specific libtool replacement may seem a little perverse, but shouldn't be too difficult, all in all). I will, however, check out libtool 1.4, as I seem to have been bitten by a limitation of 1.3.5 which is (by scanning the archives) fixed in 1.4 - if I gather correctly, a lot of ltmain.sh was reworked for 1.4 and so I'll double-check it and see if it's easily patchable to do what I want. If not, I'll go with my 'coretool' idea. Thanks for all your help. [Sorry, I forgot to mention, please CC: any replies, as I'm not subscribed to the list]. Mo. - -- Mo McKinlay [EMAIL PROTECTED] - - GnuPG/PGP Key: pub 1024D/76A275F9 2000-07-22 -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.0 (GNU/Linux) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjtUL/oACgkQRcGgB3aidfnIKgCg5SjxtSVmCg+rdnnH5ajunViu smMAoJpgF4h1jhbhPE6I/Q9ZbrsRlYHa =OyzI -END PGP SIGNATURE- ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: make check failures
On Tue, 17 Jul 2001 11:22:40 +0100, Patrick Welche wrote: > On Mon, Jul 16, 2001 at 09:05:40PM +0100, Gary V. Vaughan wrote: > > > > I am using automake from the stable branch, and autoconf-2.50, so I can't > > vouch for how well things work with development versions... you might try > > that configuration before digging too much. I have received a lot of patches > > for NetBSD, and was under the impression libtool was in pretty good shape in > > that respect... > > Yes, first time I see a failure in a long while :) That's good to hear! > Thanks for the tip.. Reason "can't dlopen the program!" - taking a look now.. Perhaps you could post the log in more detail. Thanks, Nick -- aka [EMAIL PROTECTED], [EMAIL PROTECTED] ___ Get 100% private, FREE email for life from Excite UK Visit http://inbox.excite.co.uk/ ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
Re: make check failures
A quick look says that in ltdl.c, presym_open() if you get there with a call
to lt_dlopen(0), filename is null, so
if (!filename)
{
filename = "@PROGRAM@";
}
then later:
if (!syms->address && strcmp(syms->name, filename) == 0)
as address==0, we look for syms->name == "@PROGRAM@", but name is things like
"libfoo2_LTX_nothing" or "libsub.a".. Unless the problem is that @PROGRAM@
should get substituted? (All I did was run mdemo.static with no arguments)
(BTW I just came across ltdl.c:1783 LT_DLFREE (canonical), canonical=6(!) )
I suppose the main question is: Is it just me?
Cheers,
Patrick
___
Libtool mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/libtool
Re: make check failures
On Mon, Jul 16, 2001 at 09:05:40PM +0100, Gary V. Vaughan wrote: > > I am using automake from the stable branch, and autoconf-2.50, so I can't > vouch for how well things work with development versions... you might try > that configuration before digging too much. I have received a lot of patches > for NetBSD, and was under the impression libtool was in pretty good shape in > that respect... Yes, first time I see a failure in a long while :) > You can run individual or batches of tests verbosely: > > $ VERBOSE=1 make check TESTS='mdemo-shared.test mdemo-make.test \ > mdemo-exec.test' Thanks for the tip.. Reason "can't dlopen the program!" - taking a look now.. Cheers, Patrick ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
libtool-1.4b vs. c++/gcj
Hi, Given this configure.in: AC_INIT(hello.cc) AM_INIT_AUTOMAKE(libcxx,0) AC_PROG_CXX AM_PROG_LIBTOOL AC_OUTPUT(Makefile) With autoconf-cvs and automake-cvs libtool-1.4b tries to add GCJ-support: # ./configure .. appending configuration tag "CXX" to libtool checking whether the g++ linker (/opt/gcc30/bin/ld) supports shared libraries... yes checking for g++ option to produce PIC... -fPIC checking if g++ PIC flag -fPIC works... yes checking if g++ supports -c -o file.o... no checking whether the g++ linker (/opt/gcc30/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... no checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking dynamic linker characteristics... GNU/Linux ld.so appending configuration tag "GCJ" to libtool checking if gcj supports -fno-rtti -fno-exceptions... (cached) yes checking for gcj option to produce PIC... -fPIC checking if gcj PIC flag -fPIC works... no checking if gcj supports -c -o file.o... no checking whether the gcj linker (/opt/gcc30/bin/ld) supports shared libraries... yes .. I do not understand why this configure script triggers any check for GCJ, nor do I understand why these checks claim to successfully process gcj options. .. I don't have gcj installed at all! # which gcc /opt/gcc30/bin/gcc # which gcj # gcc -v Reading specs from /opt/gcc30/lib/gcc-lib/i486-suse-linux/3.0.1/specs Configured with: ../configure --enable-threads=posix --enable-long-long --prefix=/opt/gcc30 --mandir=/opt/gcc30/man --infodir=/opt/gcc30/info --with-local-prefix=/usr/local --enable-languages=c,c++ --disable-nls --enable-shared --with-system-zlib --host=i486-suse-linux --build=i486-suse-linux Thread model: posix gcc version 3.0.1 20010713 (prerelease) Am I missing something? What triggers these GCJ-checks? Are these auto+tools versions incompatible? Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/libtool
