Thread: [Hamlib-developer] @LTLIBOBJS@
Library to control radio transceivers and receivers
Brought to you by:
n0nb
|
From: Robert <ro...@st...> - 2002-11-12 14:45:00
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi,
since my cvs update yesterday, hamlib doesn't compile.
=2E/autogen is ok, then make says:
Making all in macros
make[1]: Entering directory `/usr/src/hamlib/macros'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory `/usr/src/hamlib/macros'
Making all in include
make[1]: Entering directory `/usr/src/hamlib/include'
cd .. \
&& CONFIG_FILES=3D CONFIG_HEADERS=3Dinclude/config.h \
/bin/sh ./config.status
config.status: creating include/config.h
config.status: include/config.h is unchanged
make all-am
make[2]: Entering directory `/usr/src/hamlib/include'
make[2]: Leaving directory `/usr/src/hamlib/include'
make[1]: Leaving directory `/usr/src/hamlib/include'
Making all in lib
make[1]: Entering directory `/usr/src/hamlib/lib'
make[1]: *** No rule to make target `@LTLIBOBJS@', needed by `libmisc.la'=
=2E =20
Stop.
make[1]: Leaving directory `/usr/src/hamlib/lib'
make: *** [all-recursive] Error 1
What's wrong?
73, Robert DL1NC
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.0 (GNU/Linux)
iD8DBQE90RPmo4a8ramwUd8RAu6VAJ9NsG9zf0oBDvqFb8V0lrVf7vQIBACfaL1k
B+X+2AWYqf2O59R9gQfQ0vo=3D
=3DKogh
-----END PGP SIGNATURE-----
|
|
From: Stephane F. <f8...@fr...> - 2002-11-12 22:44:23
|
On Tue, Nov 12, 2002, Robert Steinhäußer wrote: > since my cvs update yesterday, hamlib doesn't compile. Do you mean since my commit of yesterday? When was it last time before you ran autogen.sh ? > > ./autogen is ok, then make says: > > Making all in macros > make[1]: Entering directory `/usr/src/hamlib/macros' > make[1]: Nothing to be done for `all'. > make[1]: Leaving directory `/usr/src/hamlib/macros' > Making all in include > make[1]: Entering directory `/usr/src/hamlib/include' > cd .. \ > && CONFIG_FILES= CONFIG_HEADERS=include/config.h \ > /bin/sh ./config.status > config.status: creating include/config.h > config.status: include/config.h is unchanged > make all-am > make[2]: Entering directory `/usr/src/hamlib/include' > make[2]: Leaving directory `/usr/src/hamlib/include' > make[1]: Leaving directory `/usr/src/hamlib/include' > Making all in lib > make[1]: Entering directory `/usr/src/hamlib/lib' > make[1]: *** No rule to make target `@LTLIBOBJS@', needed by `libmisc.la'. by any chance, what does "autoconf --version" and "automake --version" output? Does any one else experience the same problem? Stephane |
|
From: Robert <ro...@st...> - 2002-11-12 23:47:46
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Stephane Fillod schrieb: > On Tue, Nov 12, 2002, Robert Steinh=E4u=DFer wrote: > > since my cvs update yesterday, hamlib doesn't compile. > > Do you mean since my commit of yesterday? > When was it last time before you ran autogen.sh ? I ran `cvs update` on monday (many files had changed) and on tuesday (few= =20 files had changed). Before that, I ran an update a week ago at most. I ha= ve=20 this problem since monday. After an update, I always copy the tree and ru= n an=20 `autogen.sh` and `make` and `make install` there. > by any chance, what does "autoconf --version" and "automake --version" > output? Nothing has changed here since a couple of months... I am running SuSE 8.= 0.=20 Versions are: =09autoconf (GNU Autoconf) 2.52 =09automake (GNU automake) 1.5 Any ideas? 73, Robert -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE90ZMdo4a8ramwUd8RAvxkAKCXUC0xBhJFeyfoWj8q23XXcQHOZgCcCOQM Bylfy+zUojyh7STfW7NJ7QM=3D =3DARVv -----END PGP SIGNATURE----- |
|
From: Nate B. <n0...@ne...> - 2002-11-13 02:15:35
|
At times like this I save off any files I've been working on in the
anonymous CVS tree (anything I haven't commited or a test program I've
modified) and then blow away everything but the CVS directory under
hamlib. I then run:
cvs -z3 update -Pd
to restore the tree. It seems that major changes to the configuration
system causes all manner of problems so it seems best to start out
fresh.
The CVS manual doesn't say so explicitly, but as I read it I got the
impression it was best to delete the tree at the end of the day and
check out a new tree at the start of each day.
Since I'm no autoconf expert, this seems to work. :-)
73, de Nate >>
--
Wireless | Amateur Radio Station N0NB | "We have awakened a
Internet | n0...@ne... | sleeping giant and
Location | Bremen, Kansas USA EM19ov | have instilled in him
Amateur radio exams; ham radio; Linux info @ | a terrible resolve".
http://www.qsl.net/n0nb/ | - Admiral Yamomoto
|
|
From: Stephane F. <f8...@fr...> - 2002-11-13 22:13:35
|
On Wed, Nov 13, 2002, Robert Steinhäußer wrote:
> Nothing has changed here since a couple of months... I am running SuSE 8.0.
> Versions are:
>
> autoconf (GNU Autoconf) 2.52
> automake (GNU automake) 1.5
^^^
I remember having problems with LTLIBOBJS on some automake 1.5 versions,
which was known btw to be, hmm, development work. Even 1.6 is considered
so. It looks like the 1.7 is a lot more stable, with features working as
expected.
Okay, on some system this might be a pain to upgrade to a more recent
automake, but this what I would suggest you. I've just tested to compile
a fresh checkout, and got no problem at all (autoconf-2.54-1 and
automake1.7.1-1).
Note, --config-cache was needed with some unstable automake versions.
Since I'm not using it any more, some I'm going to update the README file.
Let me know if you're still stuck.
Stephane
|
|
From: Robert <ro...@st...> - 2002-11-21 22:26:50
|
Hi again, > I remember having problems with LTLIBOBJS on some automake 1.5 versions= , > which was known btw to be, hmm, development work. Even 1.6 is considere= d > so. It looks like the 1.7 is a lot more stable, with features working a= s > expected. > Okay, on some system this might be a pain to upgrade to a more recent > automake, but this what I would suggest you. I've just tested to compil= e > a fresh checkout, and got no problem at all (autoconf-2.54-1 and > automake1.7.1-1). > > Note, --config-cache was needed with some unstable automake versions. > Since I'm not using it any more, some I'm going to update the README fi= le. now my PCs are running Gentoo Linux 1.4RC1... it defaults to automake 1.4= -p5=20 and autoconf 2.13, but setting WANT_AUTOMAKE_1_6=3D1 calls automake 1.6.3= and=20 WANT_AUTOCONF_2_5 calls autoconf 2.54... this finally got rid of the=20 LTLIBOBJS message... now I get gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../src -I../lib -= g -O2=20 -Wall -c ft920.c -MT ft920.lo -MD -MP -MF .deps/ft920.TPlo -fPIC -DPIC -= o=20 =2Elibs/ft920.lo ft920.c: In function `ft920_set_vfo': ft920.c:814: warning: `cmd_index' might be used uninitialized in this fun= ction ft920.c: In function `ft920_get_vfo': ft920.c:924: pointers are not permitted as case values make[1]: *** [ft920.lo] Error 1 make[1]: Leaving directory `/usr/src/hamlib/yaesu' make: *** [all-recursive] Error 1 but that'll go away soon surely ;-) 73, Robert |
|
From: Stephane F. <f8...@fr...> - 2002-11-21 23:58:23
|
On Thu, Nov 21, 2002, Robert Steinhäußer wrote: > now my PCs are running Gentoo Linux 1.4RC1... it defaults to automake 1.4-p5 > and autoconf 2.13, but setting WANT_AUTOMAKE_1_6=1 calls automake 1.6.3 and > WANT_AUTOCONF_2_5 calls autoconf 2.54... this finally got rid of the > LTLIBOBJS message... now I get > > gcc -DHAVE_CONFIG_H -I. -I. -I../include -I../include -I../src -I../lib -g -O2 > -Wall -c ft920.c -MT ft920.lo -MD -MP -MF .deps/ft920.TPlo -fPIC -DPIC -o > .libs/ft920.lo > ft920.c: In function `ft920_set_vfo': > ft920.c:814: warning: `cmd_index' might be used uninitialized in this function > ft920.c: In function `ft920_get_vfo': > ft920.c:924: pointers are not permitted as case values > make[1]: *** [ft920.lo] Error 1 > make[1]: Leaving directory `/usr/src/hamlib/yaesu' > make: *** [all-recursive] Error 1 > > but that'll go away soon surely ;-) okay, I've commited a quick fix. Nate will certainly bring a better fix. This is because I wanted to roll out a new bleeding-edge version tonight, with FT-1000MP support! 73 Stephane |
|
From: Nate B. <n0...@ne...> - 2002-11-22 02:01:33
|
* Stephane Fillod <f8...@fr...> [2002 Nov 21 19:31 -0600]:
> On Thu, Nov 21, 2002, Robert Steinhäußer wrote:
> > ft920.c: In function `ft920_set_vfo':
> > ft920.c:814: warning: `cmd_index' might be used uninitialized in this function
I'm not too worried about this warning as it is quite minor. I simply
have an integer declared that may not get used in that function.
> > ft920.c: In function `ft920_get_vfo':
> > ft920.c:924: pointers are not permitted as case values
Hmmmm, this one seems strange as NULL should be a defined constant, not?
Or is NULL defined as a pointer in GNU C?
I shall investigate this a bit further, and yes it could be coded a bit
better...
> okay, I've commited a quick fix. Nate will certainly bring a better fix.
>
> This is because I wanted to roll out a new bleeding-edge version tonight,
> with FT-1000MP support!
Fortunately, we keep getting better!
73, de Nate >>
--
Wireless | Amateur Radio Station N0NB | "We have awakened a
Internet | n0...@ne... | sleeping giant and
Location | Bremen, Kansas USA EM19ov | have instilled in him
Amateur radio exams; ham radio; Linux info @ | a terrible resolve".
http://www.qsl.net/n0nb/ | - Admiral Yamomoto
|
|
From: Robert <ro...@st...> - 2002-11-28 11:17:45
|
OK, now I tried once again. Compile went fine after twiddling a bit with = the=20 settings. automake seems to be (fairly) irrelevant, i.e. I'm using standard 1.4p5. = But=20 1.6 is OK, too (at least no LIBOBJS-problem). Now the autoconf version matters. Even the newest "stable" (in my Gentoo=20 Linux) 2.53a didn't work. I have to build 2.54, which Gentoo always wants= to=20 "upgrade" to 2.53a. This procedure worked: =09# unset WANT_AUTOMAKE_1_6=09# doesn't really matter =09# export WANT_AUTOCONF_2_5 # 2.54, not 2.53a or 2.13 =09# ./autogen =09# make Perhaps including the WANT_AUTOCONF_2_5 to autogen.sh is ok? 73, Robert |
|
From: Stephane F. <f8...@fr...> - 2002-11-28 22:42:59
|
On Thu, Nov 28, 2002, Robert Steinhäußer wrote: > Perhaps including the WANT_AUTOCONF_2_5 to autogen.sh is ok? commited. A new snapshot is to come in http://hamlib.org/bleeding-edge/ 73's Stephane |
|
From: Michael S. <jam...@ea...> - 2002-11-13 11:00:53
|
I am having the same problem, and I have checked out a fresh tree (having rm'd the old) as of 0600 AM EST 11-13-2002. On Tue, 12 Nov 2002 15:44:51 +0100 Robert Steinhäußer <ro...@st...> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Hi, > > since my cvs update yesterday, hamlib doesn't compile. > > ./autogen is ok, then make says: > > Making all in macros > make[1]: Entering directory `/usr/src/hamlib/macros' > make[1]: Nothing to be done for `all'. > make[1]: Leaving directory `/usr/src/hamlib/macros' > Making all in include > make[1]: Entering directory `/usr/src/hamlib/include' > cd .. \ > && CONFIG_FILES= CONFIG_HEADERS=include/config.h \ > /bin/sh ./config.status > config.status: creating include/config.h > config.status: include/config.h is unchanged > make all-am > make[2]: Entering directory `/usr/src/hamlib/include' > make[2]: Leaving directory `/usr/src/hamlib/include' > make[1]: Leaving directory `/usr/src/hamlib/include' > Making all in lib > make[1]: Entering directory `/usr/src/hamlib/lib' > make[1]: *** No rule to make target `@LTLIBOBJS@', needed by `libmisc.la'. > Stop. > make[1]: Leaving directory `/usr/src/hamlib/lib' > make: *** [all-recursive] Error 1 > > What's wrong? > > 73, Robert DL1NC > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.2.0 (GNU/Linux) > > iD8DBQE90RPmo4a8ramwUd8RAu6VAJ9NsG9zf0oBDvqFb8V0lrVf7vQIBACfaL1k > B+X+2AWYqf2O59R9gQfQ0vo= > =Kogh > -----END PGP SIGNATURE----- > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Hamlib-developer mailing list > Ham...@li... > https://lists.sourceforge.net/lists/listinfo/hamlib-developer |
|
From: Nate B. <n0...@ne...> - 2002-11-13 12:13:03
|
* Michael Smith <jam...@ea...> [2002 Nov 13 05:42 -0600]:
>
>
> I am having the same problem, and I have checked out a fresh tree (having rm'd the old) as of 0600 AM EST 11-13-2002.
>
Hi Michael.
Looking at Robert's output, I'm curious as to whether you ran the
configure script after autogen.sh? I checked out a clean copy at 0311z
Nov 13 and had no problems. Here's what I did:
chmod +x autogen.sh
./autogen.sh --disable-static --prefix=/usr/local
./configure --enable-maintainer-mode
make
su
make uninstall
make install
I think the configure step accidentally was left out of the
README.developer file, but its use is implied in the text. Will have to
fix that!
Incidentally, even passing --disable-static to ./autogen.sh the static
libs were still built here. Perhaps this option should be passed to
./configure. The --config-cache option causes an error on my system
(Debian Sarge) when passed to either autogen.sh or configure so I don't
use it.
73, de Nate >>
--
Wireless | Amateur Radio Station N0NB | "We have awakened a
Internet | n0...@ne... | sleeping giant and
Location | Bremen, Kansas USA EM19ov | have instilled in him
Amateur radio exams; ham radio; Linux info @ | a terrible resolve".
http://www.qsl.net/n0nb/ | - Admiral Yamomoto
|
|
From: Robert <ro...@st...> - 2002-11-13 13:26:14
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Nate. > Looking at Robert's output, I'm curious as to whether you ran the > configure script after autogen.sh? I checked out a clean copy at 0311z > Nov 13 and had no problems. Here's what I did: >=20 > chmod +x autogen.sh > ./autogen.sh --disable-static --prefix=3D/usr/local > ./configure --enable-maintainer-mode > make > su > make uninstall > make install If you have a look inside autogen.sh you'll see that=20 =09$srcdir/configure --enable-maintainer-mode "$@" is called at the end. It's not neccessary to run configure again manually= =2E=20 BTW, when you run configure a second time, the flags you handed over the = first=20 fime (with autogen.sh) get lost. That's why you still get the static libs= =20 (/usr/local is default, so you won't notice that at all). The `make uninstall` shouldn't be neccessary either. If you want to remov= e the=20 old installation before installing the new one, call `make uninstall` in = the=20 old tree (before checking out the new copy). But I never did so and had n= o=20 problems so far. 73, Robert -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.0 (GNU/Linux) iD8DBQE90lLxo4a8ramwUd8RAnqVAJ9xLurl2BCKS/0hAedEHrqInee0pQCghWHt uxJFBaGmrMQvVSOVk7Ot9l4=3D =3DLI34 -----END PGP SIGNATURE----- |