Menu
▾
▴
lcd4linux-users
|
From: Michael R. <re...@eu...> - 2003-09-30 17:45:49
|
Hi Ronald,
I'm CCing this to the lcd4linux mailing list, to Martin Hejl (he has
encountered some problems while cross-compiling for uClibc) and to
Patrick Schemitz (he and me tried to build a shared library)
>>I'm resending this mail because I didn't get any any response. i hope
>>you didn't loose interest... anyway, a response would be helpful! Thanks
>>in advance!
>
> Either I didn't get it, or it got drowned in my spam filter..
Oh... or probably mine... you never can tell with spam filters :-)
>>>What exactly is the problem? Perhaps I can help..
>>
>>lcd4linux is a quite small and straightforward project, its main purpose
>>is to collect some data and display it on an LCD. It's just a simple
>>(single) application, no libraries are built.
>>
>>Now a guy wants to extract the hardware- and display-specific stuff into
>>a (shared) library, and create python bindings for it.
>>
>>lcd4linux uses autoconf and automake, which worked fine without
>>libraries. Now I tried to integrate a library target into automake. The
>>first try was a static library, which was quite easy, but for python
>>bindings you need a shared library.
>>
>>I tried to figure out how shared library targets are handled by
>>automake, and found this libtool stuff. My first try succeded, but other
>>people were having massive problems from this point on (I had to remove
>>the target again).
>>
>>one of the problems have been:
>>
>>/bin/sh ./libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.
>>-I/usr/X11R6/include -D_GNU_SOURCE -Wall -g -O2 -c display.c
>>./libtool: line 1: s%^.*/%%: No such file or directory
>>./libtool: line 1: -e: command not found
Martin, this was the error you encountered, right?
>>other people had problems with cross-compiling for uClibc...
>>
>>Maybe I did the whole autoconf/automake stuff wrong (I've no experience
>>with it).
>
> Possibly, but I'd have to see what you did with your Makefile.am files, your
> configure.{ac|in} file and what the errors were.
As you wrote later, the files look ok to you, you did already get the
package or the CVS version?
>>If I want to provide a source package, has libtool to be installed at
>>the client? autoconf/automake is not necessary, if you provide the final
>>'configure' script...
>
> No: libtoolize generates a libtool script for your package, which you should
> send along. If you make your package using `make dist', it will be packaged
> for you.
Yes, that's what I would expect.
> Your Makefile.am file looks OK (if you re-enable Libtool).
> Your configure.in file needs only one of AC_PROG_LIBTOOL and AM_PROG_LIBTOOL -
> i.e. the AC_* version.
It always worked for me. But I have all the automake/autoconf/libtool
toolchain installed.
> What versions of the autotools were you using?
merlin:~ $ autoconf --version
autoconf (GNU Autoconf) 2.57
merlin:~ $ automake --version
automake (GNU automake) 1.4-p6
merlin:~ $ libtool --version
ltmain.sh (GNU libtool) 1.5.0a (1.1220.2.25 2003/08/01 19:08:35) Debian:
49 $
merlin:~ $ libtoolize --version
libtoolize (GNU libtool) 1.5.0a
> What were the problems you
> encountered?
Martin, Patrick, could you please report your versions, too? And could
you please try to re-enable the currently commented lines in Makefile.am
and configure.in:
Makefile.am:
# deactivateing shared lib target for the moment until
# libtool works cleanly...
#lib_LTLIBRARIES = liblcd4linux.la
[...]
# deactivated
# liblcd4linux_la_LDFLAGS = -version-info 9:11:9
# liblcd4linux_la_SOURCES = \
[...]
configure.in:
# Using `AC_PROG_RANLIB' is rendered
# obsolete by `AC_PROG_LIBTOOL' :-(
AC_PROG_RANLIB
# Deactivating libtool for the moment until
# we find a way this beast works cleanly...
#AC_PROG_LIBTOOL
#AM_PROG_LIBTOOL
and the report any problems?
Lets discuss this stuff on the mailing list!
Thanks in advance to all of you! I really want to get this stuff usable.
Another guy asked for perl bindings for lcd4linux today...
bye, Michael
--
netWorks Vox: +43 316 698260
Michael Reinelt Fax: +43 316 692343
Geisslergasse 4 GSM: +43 676 3079941
A-8045 Graz, Austria e-mail: re...@eu...
|
|
From: Patrick S. <sch...@ek...> - 2003-09-30 20:39:41
|
Hello all, On Tue, Sep 30, 2003 at 07:45:40PM +0200, Michael Reinelt wrote: > >What versions of the autotools were you using? > > merlin:~ $ autoconf --version > autoconf (GNU Autoconf) 2.57 > > merlin:~ $ automake --version > automake (GNU automake) 1.4-p6 > > merlin:~ $ libtool --version > ltmain.sh (GNU libtool) 1.5.0a (1.1220.2.25 2003/08/01 19:08:35) Debian: > 49 $ > > merlin:~ $ libtoolize --version > libtoolize (GNU libtool) 1.5.0a For me, that's: $ autoconf --version autoconf (GNU Autoconf) 2.57 $ automake --version automake (GNU automake) 1.6.3 $ libtool --version ltmain.sh (GNU libtool) 1.5.0a (1.1220.2.27 2003/08/29 14:21:22) $ libtoolize --version libtoolize (GNU libtool) 1.5.0a > Martin, Patrick, could you please report your versions, too? And could > you please try to re-enable the currently commented lines in Makefile.am > and configure.in: > > Makefile.am: > # deactivateing shared lib target for the moment until > # libtool works cleanly... > #lib_LTLIBRARIES = liblcd4linux.la > [...] > # deactivated > # liblcd4linux_la_LDFLAGS = -version-info 9:11:9 > > # liblcd4linux_la_SOURCES = \ > [...] I also had to remove @DRIVERS@ from liblcd4linux_la_SOURCES, automake complained: Makefile.am:75: `liblcd4linux_la_SOURCES' includes configure substitution `@DRIVERS@', and is referred to from `liblcd4linux_la_SOURCES': configure substitutions not allowed in _SOURCES variables Plus I had to remove a lot of objects from the lcd4linux_SOURCES target since automake complained: automake: Makefile.am: object `debug.$(OBJEXT)' created both with libtool and without (Also for cfg, lock, udelay, display, pixmap, bar, icon, fontmap, and parport.) > configure.in: > # Using `AC_PROG_RANLIB' is rendered > # obsolete by `AC_PROG_LIBTOOL' :-( > AC_PROG_RANLIB > # Deactivating libtool for the moment until > # we find a way this beast works cleanly... > #AC_PROG_LIBTOOL > #AM_PROG_LIBTOOL > > and the report any problems? Configure seems to work: $ ./configure --prefix=/tmp/schemitz/trash --with-drivers=X11 [...] configure: creating ./config.status config.status: creating Makefile config.status: creating config.h config.status: executing depfiles commands $ But make fails with a curious problem. Each object seems to compile: source='display.c' object='display.lo' libtool=yes \ depfile='.deps/display.Plo' tmpdepfile='.deps/display.TPlo' \ depmode=none /bin/sh ./depcomp \ /bin/sh ./libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. -I/usr/X11R6/include -D_GNU_SOURCE -Wall -g -O2 -c -o display.lo `test -f 'display.c' || echo './'`display.c (and the same for all the other objects), but the linker complains: (cd . && ln -s display.lo display.o) [ plus the same for all the shared objects ] gcc -shared display.lo debug.lo cfg.lo lock.lo pixmap.lo bar.lo icon.lo fontmap.lo parport.lo udelay.lo -lm -Wl,-soname -Wl,liblcd4linux.0 -o .libs/liblcd4linux.0.9.11 gcc: display.lo: No such file or directory gcc: debug.lo: No such file or directory gcc: cfg.lo: No such file or directory gcc: lock.lo: No such file or directory gcc: pixmap.lo: No such file or directory gcc: bar.lo: No such file or directory gcc: icon.lo: No such file or directory gcc: fontmap.lo: No such file or directory gcc: parport.lo: No such file or directory gcc: udelay.lo: No such file or directory And the linker is right! The object files do not exist. Apparently, libtool didn't really invoke the compiler at all! Proof: mv away the gcc executable and run "make" again: no error on compile, no warning. More trouble: on the second invokation, "make" complains (again, correctly) about already existing symlinks: (cd . && ln -s display.lo display.o) ln: `display.o': File exists Hope this helps. I surely do need help here. Ciao, patrick -- Patrick Schemitz <http://www-ekp.physik.uni-karlsruhe.de/~schemitz> |
|
From: Ronald Landheer-C. <bly...@us...> - 2003-10-01 08:43:14
|
OK..
On Tue, Sep 30, 2003 at 10:39:05PM +0200, Patrick Schemitz wrote:
> I also had to remove @DRIVERS@ from liblcd4linux_la_SOURCES, automake
> complained:
>
> Makefile.am:75: `liblcd4linux_la_SOURCES' includes configure
> substitution `@DRIVERS@', and is referred to from
> `liblcd4linux_la_SOURCES': configure substitutions not allowed in
> _SOURCES variables
Try adding this at the top:
DRIVERS=@DRIVERS@
and this at the place where you removed @DRIVERS@:
$(DRIVERS)
note: use ( and ); not { and }
Let me know what the results are - I think it should help :)
rlc
|
|
From: Patrick S. <sch...@ek...> - 2003-10-02 18:28:39
|
> > I also had to remove @DRIVERS@ from liblcd4linux_la_SOURCES, automake > > complained: > > > > Makefile.am:75: `liblcd4linux_la_SOURCES' includes configure > > substitution `@DRIVERS@', and is referred to from > > `liblcd4linux_la_SOURCES': configure substitutions not allowed in > > _SOURCES variables > Try adding this at the top: > DRIVERS=@DRIVERS@ > > and this at the place where you removed @DRIVERS@: > > $(DRIVERS) $ automake configure.in:259: `DRIVERS' includes configure substitution `@DRIVERS@', and is referred to from `liblcd4linux_la_SOURCES': configure substitutions not allowed in _SOURCES variables Ciao, patrick -- Patrick Schemitz <http://www-ekp.physik.uni-karlsruhe.de/~schemitz> |
|
From: Ronald Landheer-C. <bly...@us...> - 2003-10-03 13:35:20
Attachments:
lcd4linux.diff
bootstrap
|
The attached patch will partly fix that. What still needs fixing after this patch is using Libtool to build the object files needed by DRIVERS, but that means changing configure.in to set up drivers correctly (i.e. using $(OBJEXT) in stead of .o) The patch also re-enables Libtool in configure.in, but doesn't fix DRIVERS (yet). I've also attached a bootstrap script for lcd4linux. HTH rlc On Thu, Oct 02, 2003 at 08:28:30PM +0200, Patrick Schemitz wrote: > > > I also had to remove @DRIVERS@ from liblcd4linux_la_SOURCES, automake > > > complained: > > > > > > Makefile.am:75: `liblcd4linux_la_SOURCES' includes configure > > > substitution `@DRIVERS@', and is referred to from > > > `liblcd4linux_la_SOURCES': configure substitutions not allowed in > > > _SOURCES variables > > Try adding this at the top: > > DRIVERS=@DRIVERS@ > > > > and this at the place where you removed @DRIVERS@: > > > > $(DRIVERS) > > $ automake > configure.in:259: `DRIVERS' includes configure substitution `@DRIVERS@', and is referred to from `liblcd4linux_la_SOURCES': configure substitutions not allowed in _SOURCES variables > > Ciao, patrick > -- > Patrick Schemitz <http://www-ekp.physik.uni-karlsruhe.de/~schemitz> -- One FISHWICH coming up!! |
|
From: Michael R. <re...@eu...> - 2003-10-04 07:57:38
|
Hi Ronald, first I want to thank you for your support! Ronald Landheer-Cieslak wrote: > The attached patch will partly fix that. What still needs fixing after this > patch is using Libtool to build the object files needed by DRIVERS, but > that means changing configure.in to set up drivers correctly (i.e. using > $(OBJEXT) in stead of .o) > > The patch also re-enables Libtool in configure.in, but doesn't fix DRIVERS > (yet). Ok, I applied your patch, and changed all .o to .$OBJECT in configure.in (without parens!) It works, at least for me. I checked all the cnages into CVS! But there are several questions: - is the .$OBJEXT (instead of .$(OBJEXT) correct? > I've also attached a bootstrap script for lcd4linux. - what the ehck is a bootstrap script? - should it be included - in CVS - in the distribution tarball? - is AM_PROG_LIBTOOL necessary in configure.in? (it's deactivated at the moment) - should the local 'libtool' script be included - in CVS - in the distribution tarball? - lcd4linux (the main program) is linked against the shared liblcd4linux. Is it possible to build liblcd4linux as it is now, but lcd4linux as a real standalone application (without liblcd4linux?) Would this make sense? Martin, you like small applications very much :-) Would you prefer lcd4linux depending on the shared lib, or as a independent application? Martin, Patrick: does the new version work for you? bye, Michael -- netWorks Vox: +43 316 698260 Michael Reinelt Fax: +43 316 692343 Geisslergasse 4 GSM: +43 676 3079941 A-8045 Graz, Austria e-mail: re...@eu... |
|
From: Michael R. <re...@eu...> - 2003-10-04 09:40:19
|
Hi Martin, you forgot to CC your answer to the list! >> Martin, you like small applications very much :-) Would you prefer >> lcd4linux depending on the shared lib, or as a independent application? > > Well, since usually, the (stripped) statically linked executable is > significantly (ok, 1k is already significant, in the embedded > environment I'm looking at) smaller than the (stripped) binary linked > against the (stripped) shared lib, plus the shared lib. So, unless there > is at least another app that uses that lib, I prefer the statically > linked version. Having said that, I think it would be the "cleaner" > approach to have lcd4linux link dynamically against liblcd4linux. I think so, too. I just feared that the shared lib would have some bad influences on lcd4linux, and therefore preferred not to touch lcd4linux. But if it works clean and fine, I would also use the link against shared liblcd4linux. > Just so I understand this correctly - the way it is now, _all_ I'm > supposed to do is to run configure and make, right? Ppreviously, I also > ran aclocal and autoconf, since without it, it didn't even configure > (let alone compile) on my system. Hmmm... that's what I've never been shure of, too. Whenever something strange happened while compiling, I keyed in 'auto' and pressed Tab twice, so my bash completion showed me all executables starting with 'auto'. I started them all several timne, and after a while, everything worked again :-) I think it depends wheter you're using the CVS version or the distribution tarball, because different files are included in each. I also have never been shure which files to include in either archive. Ronald? bye, Michael -- netWorks Vox: +43 316 698260 Michael Reinelt Fax: +43 316 692343 Geisslergasse 4 GSM: +43 676 3079941 A-8045 Graz, Austria e-mail: re...@eu... |
|
From: Ronald Landheer-C. <bly...@us...> - 2003-10-06 09:35:37
|
On Sat, Oct 04, 2003 at 09:57:26AM +0200, Michael Reinelt wrote:
> first I want to thank you for your support!
You're welcome :)
> Ronald Landheer-Cieslak wrote:
> >The attached patch will partly fix that. What still needs fixing after this
> >patch is using Libtool to build the object files needed by DRIVERS, but
> >that means changing configure.in to set up drivers correctly (i.e. using
> >$(OBJEXT) in stead of .o)
> >
> >The patch also re-enables Libtool in configure.in, but doesn't fix DRIVERS
> >(yet).
>
> Ok, I applied your patch, and changed all .o to .$OBJECT in configure.in
> (without parens!) It works, at least for me. I checked all the cnages
> into CVS!
>
> But there are several questions:
> - is the .$OBJEXT (instead of .$(OBJEXT) correct?
No: $(OBJEXT) is a Makefile variable, whereas $OBJEXT (or ${OBJEXT} is a shell
variable. As OBJEXT is canonically defined in the Makefile, you should use the
makefile variant.
> >I've also attached a bootstrap script for lcd4linux.
> - what the ehck is a bootstrap script?
It's the script used to launch the Autotools, to create the configure and
Makefile.in files (and libtool)
> - should it be included
> - in CVS
Yes
> - in the distribution tarball?
No.
> - is AM_PROG_LIBTOOL necessary in configure.in? (it's deactivated at the
> moment)
No: it's the deprecated form of AC_PROG_LIBTOOL
> - should the local 'libtool' script be included
> - in CVS
IMHO, no: there should be no generated files in CVS - so configure and
Makefile.in shouldn't be there either, IMHO.
Opinions may differ rather widely on this, though, but I've found it's often
more trouble than it's worth to have generated files in CVS if you have the
sources as well.
> - in the distribution tarball?
Yes.
> - lcd4linux (the main program) is linked against the shared
> liblcd4linux. Is it possible to build liblcd4linux as it is now, but
> lcd4linux as a real standalone application (without liblcd4linux?) Would
> this make sense?
Personally, I'd go for using a shared lib, but if you don't want to, the
easiest way to force static linking is to use the proper configure option
(--disable-shared). You can do that by default by checking for it in
configure.in and setting it to disabled of not explicitly set to enabled.
That way, the final choice is with the end user - the one that compiles his
own version - or with the packager, if there is one.
rlc
|
|
From: Michael R. <re...@eu...> - 2003-10-07 03:56:05
|
Hi Ronald,
>> - is the .$OBJEXT (instead of .$(OBJEXT) correct?
>
> No: $(OBJEXT) is a Makefile variable, whereas $OBJEXT (or ${OBJEXT}
> is a shell variable. As OBJEXT is canonically defined in the
> Makefile, you should use the makefile variant.
Now I understand!
>> - should the local 'libtool' script be included - in CVS
>
> IMHO, no: there should be no generated files in CVS - so configure
> and Makefile.in shouldn't be there either, IMHO. Opinions may differ
> rather widely on this, though, but I've found it's often more trouble
> than it's worth to have generated files in CVS if you have the
> sources as well.
I would agree with you, if every user who wants to try to use the CVS
version would not be forced to have the complete automake and libtool
toolchain installed.
I know there are some troubles, especially if different versions of the
toolchain are around. I think we can live with this. It's better if 5%
of CVS users have version problems than 50% have no chance to use CVS
because of their missing toolchain.
bye, Michael
--
netWorks Vox: +43 316 698260
Michael Reinelt Fax: +43 316 692343
Geisslergasse 4 GSM: +43 676 3079941
A-8045 Graz, Austria e-mail: re...@eu...
|
|
From: Michael R. <re...@eu...> - 2003-10-06 04:29:18
|
Ronald, I think I finally got it to work. I thought it worked already two days before, but this seemed do be a mistake. Ronald Landheer-Cieslak schrieb: > The attached patch will partly fix that. What still needs fixing > after this > patch is using Libtool to build the object files needed by DRIVERS, > but that means changing configure.in to set up drivers correctly > (i.e. using $(OBJEXT) in stead of .o) My main fault was that the DRIVERS list built by configure (depending on the --with-driver=...) had originally '.o' as an extension. I changed this to '.$(OBJEXT)' as you suggested. But an object file for a libtool library has to have the extension '.lo'. So I changed everything from '.$OBJEXT' to '.lo' in configure.in It seems to work now. Last Question: is there a variable holding th 'lo' string, similar to OBJEXT for the 'o'? I think it would be cleaner to use such a variable... Thanks, Michael -- netWorks Vox: +43 316 698260 Michael Reinelt Fax: +43 316 692343 Geisslergasse 4 GSM: +43 676 3079941 A-8045 Graz, Austria e-mail: re...@eu... |
|
From: Ronald Landheer-C. <bly...@us...> - 2003-10-01 08:39:40
|
On Tue, Sep 30, 2003 at 07:45:40PM +0200, Michael Reinelt wrote:
> I'm CCing this to the lcd4linux mailing list, to Martin Hejl (he has
> encountered some problems while cross-compiling for uClibc) and to
> Patrick Schemitz (he and me tried to build a shared library)
OK.
> >>>What exactly is the problem? Perhaps I can help..
> >>lcd4linux is a quite small and straightforward project, its main purpose
> >>is to collect some data and display it on an LCD. It's just a simple
> >>(single) application, no libraries are built.
> >>
> >>Now a guy wants to extract the hardware- and display-specific stuff into
> >>a (shared) library, and create python bindings for it.
> >>
> >>lcd4linux uses autoconf and automake, which worked fine without
> >>libraries. Now I tried to integrate a library target into automake. The
> >>first try was a static library, which was quite easy, but for python
> >>bindings you need a shared library.
> >>
> >>I tried to figure out how shared library targets are handled by
> >>automake, and found this libtool stuff. My first try succeded, but other
> >>people were having massive problems from this point on (I had to remove
> >>the target again).
> >>
> >>one of the problems have been:
> >>
> >>/bin/sh ./libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I.
> >>-I/usr/X11R6/include -D_GNU_SOURCE -Wall -g -O2 -c display.c
> >>./libtool: line 1: s%^.*/%%: No such file or directory
> >>./libtool: line 1: -e: command not found
> Martin, this was the error you encountered, right?
Looks like a buggy Libtool..
> >>other people had problems with cross-compiling for uClibc...
> >>Maybe I did the whole autoconf/automake stuff wrong (I've no experience
> >>with it).
> >Possibly, but I'd have to see what you did with your Makefile.am files,
> >your configure.{ac|in} file and what the errors were.
> As you wrote later, the files look ok to you, you did already get the
> package or the CVS version?
I've browsed them with ViewCVS on SourceForge.
> >Your Makefile.am file looks OK (if you re-enable Libtool).
> >Your configure.in file needs only one of AC_PROG_LIBTOOL and
> >AM_PROG_LIBTOOL -
> >i.e. the AC_* version.
>
> It always worked for me. But I have all the automake/autoconf/libtool
> toolchain installed.
>
> >What versions of the autotools were you using?
>
> merlin:~ $ autoconf --version
> autoconf (GNU Autoconf) 2.57
>
> merlin:~ $ automake --version
> automake (GNU automake) 1.4-p6
>
> merlin:~ $ libtool --version
> ltmain.sh (GNU libtool) 1.5.0a (1.1220.2.25 2003/08/01 19:08:35) Debian:
> 49 $
>
> merlin:~ $ libtoolize --version
> libtoolize (GNU libtool) 1.5.0a
>
>
> >What were the problems you
> >encountered?
>
> Martin, Patrick, could you please report your versions, too? And could
> you please try to re-enable the currently commented lines in Makefile.am
> and configure.in:
note: if their versions and your versions are not the same, it might work for
you but not for them, as the package will be re-bootstrapped. Generally, only
developers should re-bootstrap packages: end-users shouldn't touch the
Makefile.am or configure.in files as the changes they make will have impacts
other than just their changes on the generated scripts if their versions
differ from yours.
I'll subscribe to the list :)
rlc
--
I just need enough to tide me over until I need more.
-- Bill Hoest
|
|
From: Martin H. <ma...@he...> - 2003-10-01 10:12:57
|
Hi Michael. Michael Reinelt wrote: >>> one of the problems have been: >>> >>> /bin/sh ./libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I. >>> -I/usr/X11R6/include -D_GNU_SOURCE -Wall -g -O2 -c display.c >>> ./libtool: line 1: s%^.*/%%: No such file or directory >>> ./libtool: line 1: -e: command not found > > > Martin, this was the error you encountered, right? Correct. The full error I got was: /bin/sh ./libtool --mode=link /nfs/ghlx02/stuff/sourceforge/src/bering-uclibc/buildtool/staging/usr/bin/gcc -D_GNU_SOURCE -Wall -Os -s -I/nfs/ghlx02/stuff/sourceforge/src/bering-uclibc/buildtool/staging/include:/nfs/ghlx02/stuff/sourceforge/src/bering-uclibc/buildtool/staging/include/include -o lcd4linux lcd4linux.o debug.o cfg.o lock.o pid.o parser.o processor.o system.o isdn.o mail.o seti.o battery.o dvb.o filter.o udelay.o display.o pixmap.o bar.o icon.o fontmap.o exec.o mail2.o socket.o BeckmannEgle.o Crystalfontz.o Cwlinux.o HD44780.o M50530.o T6963.o USBLCD.o MatrixOrbital.o parport.o -lm ./libtool: s%^.*/%%: No such file or directory ./libtool: -e: command not found ./libtool: -e: command not found ./libtool: -e: command not found ./libtool: -e: command not found ./libtool: -e: command not found ./libtool: -e: command not found ./libtool: -e: command not found ./libtool: -e: command not found ./libtool: -e: command not found > Martin, Patrick, could you please report your versions, too? $autoconf --version autoconf (GNU Autoconf) 2.57 Written by David J. MacKenzie and Akim Demaille. $automake --version automake (GNU automake) 1.6.3 Written by Tom Tromey <tr...@re...>. $libtool --version ltmain.sh (GNU libtool) 1.4.2 (1.922.2.53 2001/09/11 03:18:52) $ libtoolize --version libtoolize (GNU libtool) 1.4.2 Looking at the versions you posted, it looks like my version of libtool is pretty old - I'll update that to something more current as soon as I have time. Martin |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X