On my UnixWare box, I tested with a GNU grep first in the path and #21
did not fail. Now, which part is tripping up the system grep and what
to do about it, I do not know. ;-)
--
Tim RiceMultitalents(707) 456-1146
t...@multitalents.net
lib/libgettextlib.la
[snip]
> Are the *.la files supposed to be executable?
Since libtool sources the .la files, they do not need to be executable.
You will see a mix of executable and non-executable in various distos.
My packaging scripts do a chmod 644 on th
.
rm src/libssh2.la
SCOABSPATH=1 ; export SCOABSPATH
gmake 2>&1 | tee x.log
..
then package.
Note: the last hunk is to address a regression introduced in 2.4.6
with the freebsd reorg.
--
Tim RiceMultitalents
t...@multitalents.net
--- libtool.old
REL
> 0x0017 (JMPREL) 0xfb18
> 0x0011 (REL)0x9e60
> 0x0012 (RELSZ) 23736 (bytes)
> 0x0013 (RELENT) 8 (bytes)
> 0x (NULL) 0x0
>
> I'm assuming there must be something else different in the way we build.
Which development system are you using?
OpenServer 5.0..7 had 3 different ones available.
OpenServer 5 Definitive 2018 has 4. The latest being a GCC 4.2.4 and friends.
>
> Regards,
> Kevin R. Bulgrien
>
--
Tim RiceMultitalents
t...@multitalents.net
ut is this possible
with the current design of CVS HEAD?
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
grams is supported.
-dlopen_self=unknown
+dlopen_self=no
# Whether dlopen of statically linked programs is supported.
dlopen_self_static=unknown
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
___
and not any of the build paths (e.g. ~/src/project1/blah).
>
I'd like to be able have the embedded runpath be /opt/lib even
if I install in /opt/foo/lib. (the package posinstall script would put
symbolic links in /opt/lib)
--
Tim RiceMultitalents(
On Tue, 27 Sep 2005, Ralf Wildenhues wrote:
> Hi Tim,
>
> * Tim Rice wrote on Tue, Sep 27, 2005 at 07:56:31PM CEST:
> > I'd like to be able have the embedded runpath be /opt/lib even
> > if I install in /opt/foo/lib. (the package posinstall script would put
> > sy
itten to sub/main
stdout:
libtool: link: CC -g -o sub/main sub/main.o lib2/.libs/libb.a lib/.libs/liba.a
template.at:214: ./sub/main; lt_status=$?; if test $lt_status -eq 0; then :;
elif test "X$host" != "X$build" && \
{ test -x "./sub/main" || test -x "./sub/main"$EXEEXT; }
then (exit 77); else (exit $lt_status); fi
0a1
> UX:ksh: ERROR: ./sub/main: not found
19. template.at:115: 19. template test with subdirs (template.at:115): FAILED
(template.at:214)
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
the next release. I suspect
Kean will not be able to post them to libtool-patches before monday
or tuesday.
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
this an automake 1.9.6 bug?
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
On Sun, 30 Oct 2005, Ralf Wildenhues wrote:
> Sorry for self-reply.
>
> * Ralf Wildenhues wrote on Sun, Oct 30, 2005 at 02:08:14AM CET:
> > * Tim Rice wrote on Sun, Oct 30, 2005 at 01:41:22AM CEST:
> > >
> > > The native c/CC compilers on the that machine does no
On Sun, 30 Oct 2005, Ralf Wildenhues wrote:
> Hi Tim,
>
> * Tim Rice wrote on Sun, Oct 30, 2005 at 02:34:18AM CET:
> > On Sun, 30 Oct 2005, Ralf Wildenhues wrote:
> > > I guess you should be able to use this manually-written rule as a
> > > worka
Is it intentional that the new test suite only gets run
if the old test suite passes?
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
13 fail if the system you are testing on has no autoconf?
Perhaps it should pass.
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
On Sun, 30 Oct 2005, Tim Rice wrote:
> .
> 13. old-m4-iface.at:34: testing ...
> libtoolize: linking file `./config.guess'
> libtoolize: linking file `./config.sub'
> libtoolize: linking file `./install-sh'
> libtoolize: linking file `./ltmain.sh'
> l
nk you for any help as well as finding problem which can be also in path
> I look forward hearing from you
>
> Yours faithfully
>
> Peter Fodrek
>
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
On Thu, 17 Nov 2005, peto wrote:
> D??a ??t 17. November 2005 19:46 Tim Rice nap??sal:
>
> > > [EMAIL PROTECTED] peto]$ libtool --version
> > > ltmain.sh (GNU libtool) 1.4.3 (1.922.2.110 2002/10/23 01:39:54)
> > > [EMAIL PROTECTED] peto]$ libtool --confi
building of targets.
> With my first attempt at going 64 bit, I hit a problem since libtool
> seems to configure only 32bit (at least for creating shared objects). Am
> I missing something that I could do to make the leap to 64 bit?
Try CC="gcc -m64" ./configure ....
>
{PACKAGE}-${VER} \
--libdir=/opt/lib/64\
--mandir=/opt/mt/${PACKAGE}-${VER}/man \
--enable-shared \
2>&1 | tee x.conf
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
_
On Sun, 18 Feb 2007, Ralf Wildenhues wrote:
> Hello Tim,
> Tim Rice writes:
> >
> > Should a single libtool handle both 32bit & 64bit builds on Solaris
> > with Sun Studio 11?
>
> No.
[snip]
> Also please note the multilib fixes that are new in 1.5.
I'm getting an "UNEXPECTED PASS" on test 30 of the new test suite
on my UnixWare 7.1.4 box.
A testlog generated with "gmake check-local TESTSUITEFLAGS='-d -x 30'" is
attached.
I don't seem to understand the new test suite well
On Fri, 8 Feb 2008, Ralf Wildenhues wrote:
> * Tim Rice wrote on Fri, Feb 08, 2008 at 03:00:05AM CET:
> > I'm getting an "UNEXPECTED PASS" on test 30 of the new test suite
> > on my UnixWare 7.1.4 box.
>
> Thanks for the bug report. I've installed
On Sun, 10 Feb 2008, Ralf Wildenhues wrote:
> [ cutting libtool-patches ]
>
> Hi Tim,
>
> * Tim Rice wrote on Sun, Feb 10, 2008 at 12:05:33AM CET:
> > Now only 54, 55 and of course 64 (because 54 & 55 fail) fail on
> > UnixWare 7.1.4. There is still some work
CVS HEAD pulled Fri Feb 8 17:52:22 PST 2008
Solaris 10 w/ SunStudio 11
I'm seeing failures in 64 bit mode I don't see in 32 bit mode with
compiler options that woked for me in both 32 & 64 on branch-1.5.
testsuite.log-64.gz attached.
--
Tim Rice
Hi Ralf,
On Mon, 11 Feb 2008, Ralf Wildenhues wrote:
> * Tim Rice wrote on Mon, Feb 11, 2008 at 06:23:59AM CET:
> > CVS HEAD pulled Fri Feb 8 17:52:22 PST 2008
> > Solaris 10 w/ SunStudio 11
> >
> > I'm seeing failures in 64 bit mode I don't see in 32 bi
Is there a miniumum version of m4 to build/test libtool-2.2.6 and later?
Thanks.
--
Tim RiceMultitalents(707) 887-1469
[EMAIL PROTECTED]
___
http://lists.gnu.org/mailman/listinfo/libtool
Hi Ralf,
On Sat, 21 Feb 2009, Ralf Wildenhues wrote:
> Hi Tim,
>
> * Tim Rice wrote on Fri, Feb 20, 2009 at 09:29:40PM CET:
> >
> > I'm trying to understand the cmdline_wrap.at test.
> > I've added this patch to fix the 2 template tests that were failing
&g
I noticed that the SCOABSPATH bits are in aclocal.m4 on 2.2.6 and
was wondering how they got there since the corresponding changes
to libltdl/m4/libtool.m4 were intentionally not forward ported from
the 1.5 branch.
--
Tim RiceMultitalents(707) 887-1469
t
Hi Ralf,
On Wed, 25 Feb 2009, Ralf Wildenhues wrote:
: Hi Tim,
:
: * Tim Rice wrote on Mon, Feb 23, 2009 at 10:47:49PM CET:
: > On Sat, 21 Feb 2009, Ralf Wildenhues wrote:
: > > * Tim Rice wrote on Fri, Feb 20, 2009 at 09:29:40PM CET:
: > > >
: > > > I
ep -n "^reload_cmds=" libtool
123:reload_cmds="\$LD\$reload_flag -o \$output\$reload_objs"
t...@server01-unixware 134% grep -n "CONFIG: CXX" libtool
9097:# ### BEGIN LIBTOOL TAG CONFIG: CXX
9245:# ### END LIBTOOL TAG CONFIG: CXX
.
--
Tim Rice
31 matches
Mail list logo
