amanda-2.4.3b3 and tapeless backup
hi all, i'm trying to do tapeless backup with the amanda-2.4.3b3 The tapedevice is set as follow: runtapes 1 tapedev file:/home/amanda/backup if /home/amanda/backup is empty i get... ]$ amcheck config #Amanda Tape Server Host Check #- #Holding disk /home/amanda/backup: 60136384 KB disk space available, #that's plenty #ERROR: file:/home/amanda/backup: rewinding tape: Input/output error # (expecting a new tape) #NOTE: skipping tape-writable test #Server check took 0.001 seconds if i create the subdirectory data i get the following error: ]$ amcheck config #Amanda Tape Server Host Check #- #Holding disk /home/amanda/backup: 60136380 KB disk space available, #that's plenty #ERROR: file:/home/amanda/backup: not an amanda tape # (expecting a new tape) #NOTE: skipping tape-writable test #Server check took 0.000 seconds i'm wondering what should contain the /home/amanda/backup/ directory to emulate a tape .? -- Pierre-yves Verdon Wanadoo Portails (FRANCE) -- First they ignore you Then they laugh at you Then they fight you Then you win --Mahatma Gandhi
Re: amanda-2.4.3b3-20020324 problem
On Sun, Mar 24, 2002 at 10:12:43PM -0500, Gene Heskett wrote: On Sunday 24 March 2002 05:16 pm, Jean-Louis Martineau wrote: On Sun, Mar 24, 2002 at 10:06:41PM +0100, Thomas Hepper wrote: Yup there was an bug introduced in chg-scsi which will cause an endless loop on readingthe config file, fixed in CVS so wait for the next snapshot. A new snapshot is already available. Jean-Louis I just grabbed it again at 21:00 my time, making note that the tar.gz was exactly the same size, and its still broken. I think it is your site I'm getting my snapshots from. http://www.iro.umontreal.ca/~martinea/amanda-2.4.3b3-20020324.tar.gz It's http://www.iro.umontreal.ca/~martinea/amanda/amanda-2.4.3b3-20020324.tar.gz No more up to date site. I build a snapshot every time someone commit something on CVS, I don't know if it compile. I don't know if your bug is fixed. Latest snapshot have: md5sum amanda-2.4.3b3-20020324.tar.gz f74bc9822c6cf1d8624819cac6fbff16 amanda-2.4.3b3-20020324.tar.gz Maybe you have a caching problem. Jean-Louis -- Jean-Louis Martineau email: [EMAIL PROTECTED] Departement IRO, Universite de Montreal C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529 Montreal, Canada, H3C 3J7Fax: (514) 343-5834
Re: amanda-2.4.3b3-20020324 problem
On Sunday 24 March 2002 05:16 pm, Jean-Louis Martineau wrote: On Sun, Mar 24, 2002 at 10:06:41PM +0100, Thomas Hepper wrote: Yup there was an bug introduced in chg-scsi which will cause an endless loop on readingthe config file, fixed in CVS so wait for the next snapshot. A new snapshot is already available. Jean-Louis I just grabbed it again at 21:00 my time, making note that the tar.gz was exactly the same size, and its still broken. I think it is your site I'm getting my snapshots from. http://www.iro.umontreal.ca/~martinea/amanda-2.4.3b3-20020324.tar.gz Is there another, more up to date site? -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 98.7+% setiathome rank, not too shabby for a hillbilly
Re: amanda-2.4.3b3-20020324 problem
On Monday 25 March 2002 12:38 am, Jean-Louis Martineau wrote: On Sun, Mar 24, 2002 at 10:12:43PM -0500, Gene Heskett wrote: On Sunday 24 March 2002 05:16 pm, Jean-Louis Martineau wrote: On Sun, Mar 24, 2002 at 10:06:41PM +0100, Thomas Hepper wrote: Yup there was an bug introduced in chg-scsi which will cause an endless loop on readingthe config file, fixed in CVS so wait for the next snapshot. A new snapshot is already available. Jean-Louis I just grabbed it again at 21:00 my time, making note that the tar.gz was exactly the same size, and its still broken. I think it is your site I'm getting my snapshots from. http://www.iro.umontreal.ca/~martinea/amanda-2.4.3b3-20020324 .tar.gz It's http://www.iro.umontreal.ca/~martinea/amanda/amanda-2.4.3b3-20 020324.tar.gz No more up to date site. I build a snapshot every time someone commit something on CVS, I don't know if it compile. I don't know if your bug is fixed. Latest snapshot have: md5sum amanda-2.4.3b3-20020324.tar.gz f74bc9822c6cf1d8624819cac6fbff16 amanda-2.4.3b3-20020324.tar.gz Now I don't know, Jean-Louis. I'd rm'd both the build directory and the archive before going after it again last nite, but I get ae9f2fea5b79cde0357506728b01f93d for the md5sum of what I got for the 3rd time last night. It still has a time of just after 1800 the 24th. Maybe you have a caching problem. Possibly, but I don't /think/ its me, no copy existed on either of my machines at the time of the last download. I'll just wait till the next snapshot, this is not that big a deal except for those users of chg-scsi, and the 20020311 version seems to be chugging right along, no problems other than it overran the first tape last night and had to use most (3.5g) of the second tape too. It was odd, and was the first time it has done that but it worked ok according to the email it sent me. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 98.7+% setiathome rank, not too shabby for a hillbilly
Re: amanda-2.4.3b3-20020324 problem
On Monday 25 March 2002 12:38 am, Jean-Louis Martineau wrote: Latest snapshot have: md5sum amanda-2.4.3b3-20020324.tar.gz f74bc9822c6cf1d8624819cac6fbff16 amanda-2.4.3b3-20020324.tar.gz Maybe you have a caching problem. Which was exactly it, mozilla's cache TBE. My apologies. -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 98.7+% setiathome rank, not too shabby for a hillbilly
amanda-2.4.3b3-20020324 problem
Hi everybody, back from a week in FL that included a trip to the Cape, nice to have kin with a pad in Mt. Dora. I was running 2.4.3b3-20020311 at the time. I'd left amanda to fill the holding disk while I was gone, and it appeared to have had an access problem according to the mails because I had shut the gateway machine off while I was gone, which presumably was the target of amanda's gethostbyname activities. A couple of amflushes and that was cleaned up though, but I need someone to tell me the *right* syntax to have amflush /config/ do a thru c, then d thru the end, etc because apparently the only acceptable syntax was 'all'. And somehow, even that fit on one 4g tape Then I toured the .ca site for new releases, finding 2.4.3b3-20020324 as the newest one, so I grabbed it, and built it, and installed it as per the usual configuration here. But it hangs while doing '/usr/local/libexec/chg-scsi -info' (don't take the above path as gospel, I've driven 1100 miles in the last 24 hrs) with that process using 86% of the cpu, apparently forever, or until a ctrl c is applied. Kinda slows up setiathome though. :-) Re-installing amanda-2.4.3b3-20020311 seems to bring things back to normal. Didja change something in the chg-scsi.conf requirements column while I was out getting some sand in my shoes? Or is this just the usual beta testing squiggle? -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 98.7+% setiathome rank, not too shabby for a hillbilly
Re: amanda-2.4.3b3-20020324 problem
Hi Gene, On Sun, Mar 24, 2002 at 03:20:35PM -0500, Gene Heskett wrote: [..] But it hangs while doing '/usr/local/libexec/chg-scsi -info' (don't take the above path as gospel, I've driven 1100 miles in the last 24 hrs) with that process using 86% of the cpu, apparently forever, or until a ctrl c is applied. Kinda slows up setiathome though. :-) Yup there was an bug introduced in chg-scsi which will cause an endless loop on readingthe config file, fixed in CVS so wait for the next snapshot. Re-installing amanda-2.4.3b3-20020311 seems to bring things back to normal. Didja change something in the chg-scsi.conf requirements column while I was out getting some sand in my shoes? Or is this just the usual beta testing squiggle? Si, that's the life with beta versions (grumbel gnn) Thomas -- --- | Thomas Hepper[EMAIL PROTECTED] | | ( If the above address fail try ) | | ( [EMAIL PROTECTED])| ---
Re: amanda-2.4.3b3-20020324 problem
... I need someone to tell me the *right* syntax to have amflush /config/ do a thru c, then d thru the end, etc because apparently the only acceptable syntax was 'all'. ... I didn't realize this until I was cleaning up some code yesterday, but you can enter more than one letter at that prompt separated by commas or whitespace. So you should have been able to do: a, b, c When that was done, you could do another amflush to pick off the rest (or do another subset, etc). I've taken a note to myself to get this in the man page. But it hangs while doing '/usr/local/libexec/chg-scsi -info' ... My fault. I botched a mod yesterday and Thomas Hepper has already fixed it. Gene John R. Jackson, Technical Software Specialist, [EMAIL PROTECTED]
Re: amanda-2.4.3b3-20020324 problem
On Sun, Mar 24, 2002 at 10:06:41PM +0100, Thomas Hepper wrote: Yup there was an bug introduced in chg-scsi which will cause an endless loop on readingthe config file, fixed in CVS so wait for the next snapshot. A new snapshot is already available. Jean-Louis -- Jean-Louis Martineau email: [EMAIL PROTECTED] Departement IRO, Universite de Montreal C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529 Montreal, Canada, H3C 3J7Fax: (514) 343-5834
Re: amanda-2.4.3b3-20020324 problem
On Sunday 24 March 2002 05:16 pm, Jean-Louis Martineau wrote: On Sun, Mar 24, 2002 at 10:06:41PM +0100, Thomas Hepper wrote: Yup there was an bug introduced in chg-scsi which will cause an endless loop on readingthe config file, fixed in CVS so wait for the next snapshot. A new snapshot is already available. Jean-Louis I just grabbed it again at 21:00 my time, making note that the tar.gz was exactly the same size, and its still broken. I think it is your site I'm getting my snapshots from. http://www.iro.umontreal.ca/~martinea/amanda-2.4.3b3-20020324.tar.gz Is there another, more up to date site? -- Cheers, Gene AMD K6-III@500mhz 320M Athlon1600XP@1400mhz 512M 98.7+% setiathome rank, not too shabby for a hillbilly
Re: amanda-2.4.3b3-20020324 problem
On Sun, Mar 24, 2002 at 10:12:43PM -0500, Gene Heskett wrote: On Sunday 24 March 2002 05:16 pm, Jean-Louis Martineau wrote: On Sun, Mar 24, 2002 at 10:06:41PM +0100, Thomas Hepper wrote: Yup there was an bug introduced in chg-scsi which will cause an endless loop on readingthe config file, fixed in CVS so wait for the next snapshot. A new snapshot is already available. Jean-Louis I just grabbed it again at 21:00 my time, making note that the tar.gz was exactly the same size, and its still broken. I think it is your site I'm getting my snapshots from. http://www.iro.umontreal.ca/~martinea/amanda-2.4.3b3-20020324.tar.gz It's http://www.iro.umontreal.ca/~martinea/amanda/amanda-2.4.3b3-20020324.tar.gz No more up to date site. I build a snapshot every time someone commit something on CVS, I don't know if it compile. I don't know if your bug is fixed. Latest snapshot have: md5sum amanda-2.4.3b3-20020324.tar.gz f74bc9822c6cf1d8624819cac6fbff16 amanda-2.4.3b3-20020324.tar.gz Maybe you have a caching problem. Jean-Louis -- Jean-Louis Martineau email: [EMAIL PROTECTED] Departement IRO, Universite de Montreal C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529 Montreal, Canada, H3C 3J7Fax: (514) 343-5834
libtool problem with amanda-2.4.3b3 build
I recently posted some build data about versions 2p2 and 3b3 with regard to the results of various configure options related to libtool as well as changing the version of libtool... The 2p2 builds performed without a problem when --disable-libtool was set or unset. The 3b3 build dies with libtool errors REGARDLESS of whether --disable-libtool is set or not. Would this not indicate a problem with the build? Regardless of whether or not there is a problem with libtool on the Alpha/Tru64 box?... If one says --disable-libtool what should one expect? A broken build with libtoool errors as the cuplrit? Maybe my problem is not libtool when the --disable-libtool option is specified... thx dk
amanda-2.4.3b3 and libtool on Tru64 5.0
My issue is with libtool related failures when building 2.4.3b3 I tried several things suggested to me: o Am I running configure on a clean source tree? YES, freshly unpacked. o Have I tried: + downgrading libtool? YES to 1.3.4. Then re-intalled the 1.4.2 version again. Results of build are consistently the same on both 2.4.2p2 and 2.4.3b3 source trees, with either version. + upgrading libtool to beta version? NO... All I could find was an alpha/development version. + specifying the --disable-libtool? No need with 2.4.2p2 since this problem does not occur. With 2.4.3b3, this allows compilation to not fail until later with a libtool error Here is the output of 2.4.3b3 build with the --disable-libtool specified at the configure stage: # config.status: creating config/Makefile config.status: creating Makefile config.status: creating config/config.h Making all in config make[1]: Entering directory `/net/redbelly/scratch1/Admin/Build/amanda-2.4.3b3/config' cd .. \ CONFIG_FILES= CONFIG_HEADERS=config/config.h \ /usr/bin/sh ./config.status config.status: creating config/config.h config.status: config/config.h is unchanged make all-am make[2]: Entering directory `/net/redbelly/scratch1/Admin/Build/amanda-2.4.3b3/config' make[2]: Leaving directory `/net/redbelly/scratch1/Admin/Build/amanda-2.4.3b3/config' make[1]: Leaving directory `/net/redbelly/scratch1/Admin/Build/amanda-2.4.3b3/config' Making all in common-src make[1]: Entering directory `/net/redbelly/scratch1/Admin/Build/amanda-2.4.3b3/common-src' source='alloc.c' object='alloc.o' libtool=no \ depfile='.deps/alloc.Po' tmpdepfile='.deps/alloc.TPo' \ depmode=gcc3 /usr/bin/sh ../config/depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src -I/usr/local/gnu/include -O2 -c `test -f alloc.c || echo './'`alloc.c source='amflock.c' object='amflock.o' libtool=no \ depfile='.deps/amflock.Po' tmpdepfile='.deps/amflock.TPo' \ depmode=gcc3 /usr/bin/sh ../config/depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src -I/usr/local/gnu/include -O2 -c `test -f amflock.c || echo './'`amflock.c source='debug.c' object='debug.o' libtool=no \ depfile='.deps/debug.Po' tmpdepfile='.deps/debug.TPo' \ depmode=gcc3 /usr/bin/sh ../config/depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src -I/usr/local/gnu/include -O2 -c `test -f debug.c || echo './'`debug.c source='dgram.c' object='dgram.o' libtool=no \ depfile='.deps/dgram.Po' tmpdepfile='.deps/dgram.TPo' \ depmode=gcc3 /usr/bin/sh ../config/depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src -I/usr/local/gnu/include -O2 -c `test -f dgram.c || echo './'`dgram.c dgram.c: In function `dgram_recv': dgram.c:292: warning: passing arg 6 of `recvfrom' from incompatible pointer type source='error.c' object='error.o' libtool=no \ depfile='.deps/error.Po' tmpdepfile='.deps/error.TPo' \ depmode=gcc3 /usr/bin/sh ../config/depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src -I/usr/local/gnu/include -O2 -c `test -f error.c || echo './'`error.c source='file.c' object='file.o' libtool=no \ depfile='.deps/file.Po' tmpdepfile='.deps/file.TPo' \ depmode=gcc3 /usr/bin/sh ../config/depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src -I/usr/local/gnu/include -O2 -c `test -f file.c || echo './'`file.c source='fileheader.c' object='fileheader.o' libtool=no \ depfile='.deps/fileheader.Po' tmpdepfile='.deps/fileheader.TPo' \ depmode=gcc3 /usr/bin/sh ../config/depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src -I/usr/local/gnu/include -O2 -c `test -f fileheader.c || echo './'`fileheader.c sh ./../regex-src/mkh -o -i _REGEX_H_ ./../regex-src/regex2.h ./../regex-src/regcomp.c ./../regex-src/regexec.c ./../regex-src/regerror.c ./../regex-src/regfree.c regex.h source='match.c' object='match.o' libtool=no \ depfile='.deps/match.Po' tmpdepfile='.deps/match.TPo' \ depmode=gcc3 /usr/bin/sh ../config/depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src -I/usr/local/gnu/include -O2 -c `test -f match.c || echo './'`match.c source='protocol.c' object='protocol.o' libtool=no \ depfile='.deps/protocol.Po' tmpdepfile='.deps/protocol.TPo' \ depmode=gcc3 /usr/bin/sh ../config/depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src -I/usr/local/gnu/include -O2 -c `test -f protocol.c || echo './'`protocol.c sh ./../regex-src/mkh -o -p ./../regex-src/regcomp.c regcomp.ih source='regcomp.c' object='regcomp.o' libtool=no \ depfile='.deps/regcomp.Po' tmpdepfile='.deps/regcomp.TPo' \ depmode=gcc3 /usr/bin/sh ../config/depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src -I/usr/local/gnu/include -O2 -c `test -f regcomp.c || echo './'`regcomp.c sh ./../regex-src/mkh -o -p ./../regex-src/regerror.c regerror.ih source='regerror.c' object='regerror.o' libtool
amanda 2.4.3b3
The Amanda core team is pleased to announce the release of Amanda 2.4.3b3. It is the third beta release of 2.4.3. All known bugs are fixed. It can be dowloaded from http://www.amanda.org/ This release include a change in the behavior of the exclude option in a dumptype. It it now possible to have many 'exclude' and many 'exclude list' simultaneously. In previous release, only the last one was used. Look at the amanda man page for a description. The command 'amadmin config disklist' will show the exclude used. You need to upgrade the server and client to use multiple exclude, you will get the following message from amcheck if your client is not upgraded: ahost /usr lev 0 FAILED [badly formatted response from ahost] The new 'include' option in a dumptype and the new format of a disklist entry (diskdevice different than the diskname) make it easier to separate a disk in multiple disklist entry using GNUTAR. Look at the amanda man page and example/disklist file for example on how to use it. You need to upgrade the server and client to use 'include' or the new disklist format. Here's a list of the changes for release 2.4.3b3 (from the NEWS file): Look at the ChangeLog file for more details. * --with-maxtapeblocksize configure options * blocksize tapetype option * file-pad tapetype option * Multiple exclude in dumptype * Option include in dumptype * New disklist syntax: * hostname diskname [ diskdevice ] dumptype [ spindle [ interface ] ] * chg-zd-mtx: Major cleanup and general overhaul. * amrecover: new listdisk command. Jean-Louis -- Jean-Louis Martineau email: [EMAIL PROTECTED] Departement IRO, Universite de Montreal C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529 Montreal, Canada, H3C 3J7Fax: (514) 343-5834
Re: amanda 2.4.3b3
Hello John, Maybe libtool doesn't support your OSF1 V5.1 732 alpha. You can debug libtool or configure with --disable-libtool Jean-Louis On Fri, Mar 08, 2002 at 01:52:50PM -0800, John Koenig wrote: Thank you for all your (and everyone else involved) hard work... Though... I am having build issues... Can someone suggest soemething that I should examine (and fix) to make the build work properly? thank you... -JFK # config.status: creating Makefile config.status: creating config/config.h Making all in config make[1]: Entering directory `/net/redbelly/scratch1/Admin/Build/amanda-2.4.3b3/config' cd .. \ CONFIG_FILES= CONFIG_HEADERS=config/config.h \ /usr/bin/sh ./config.status config.status: creating config/config.h config.status: config/config.h is unchanged make all-am make[2]: Entering directory `/net/redbelly/scratch1/Admin/Build/amanda-2.4.3b3/config' make[2]: Leaving directory `/net/redbelly/scratch1/Admin/Build/amanda-2.4.3b3/config' make[1]: Leaving directory `/net/redbelly/scratch1/Admin/Build/amanda-2.4.3b3/config' Making all in common-src make[1]: Entering directory `/net/redbelly/scratch1/Admin/Build/amanda-2.4.3b3/common-src' source='alloc.c' object='alloc.lo' libtool=yes \ depfile='.deps/alloc.Plo' tmpdepfile='.deps/alloc.TPlo' \ depmode=tru64 /usr/bin/sh ../config/depcomp \ /usr/bin/sh ../libtool --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src -I/usr/local/gnu/include -O2 -c -o alloc.lo `test -f alloc.c || echo './'`alloc.c ../libtool: print: not found ../libtool: print: not found ../libtool: print: not found ../libtool: print: not found ../libtool: print: not found ../libtool: print: not found ../libtool: print: not found ../libtool: print: not found ../libtool: print: not found ../libtool: print: not found ../libtool: print: not found ../libtool: print: not found ../libtool: print: not found ../libtool: print: not found ../libtool: print: not found make[1]: *** [alloc.lo] Error 1 make[1]: Leaving directory `/net/redbelly/scratch1/Admin/Build/amanda-2.4.3b3/common-src' make: *** [all-recursive] Error 1 # The Amanda core team is pleased to announce the release of Amanda 2.4.3b3. It is the third beta release of 2.4.3. All known bugs are fixed. -- Jean-Louis Martineau email: [EMAIL PROTECTED] Departement IRO, Universite de Montreal C.P. 6128, Succ. CENTRE-VILLETel: (514) 343-6111 ext. 3529 Montreal, Canada, H3C 3J7Fax: (514) 343-5834
Re: amanda 2.4.3b3
Hello again...
I took the advice and inserted --disable-libtool into my configure.
(OSF1 V5.1 732 alpha)
Files actually started to compile this time instead of dying right at the
beginning..
This time... not long after some files *did* compile, it seems the broken libtool
invocation showed up again... How can that be? I said 'disable-libtool'.
Does this information plus the fact that the 2.4.2p2 build worked fine without the
disabling the use of libtool, provide any useful information to the maintainers?
###
Here is my output from the most recent build attempt of amanda-2.4.3b3:
config.status: creating Makefile
config.status: creating config/config.h
Making all in config
make[1]: Entering directory `/net/redbelly/scratch1/Admin/Build/amanda-2.4.3b3/config'
cd .. \
CONFIG_FILES= CONFIG_HEADERS=config/config.h \
/usr/bin/sh ./config.status
config.status: creating config/config.h
config.status: config/config.h is unchanged
make all-am
make[2]: Entering directory `/net/redbelly/scratch1/Admin/Build/amanda-2.4.3b3/config'
make[2]: Leaving directory `/net/redbelly/scratch1/Admin/Build/amanda-2.4.3b3/config'
make[1]: Leaving directory `/net/redbelly/scratch1/Admin/Build/amanda-2.4.3b3/config'
Making all in common-src
make[1]: Entering directory
`/net/redbelly/scratch1/Admin/Build/amanda-2.4.3b3/common-src'
source='alloc.c' object='alloc.o' libtool=no \
depfile='.deps/alloc.Po' tmpdepfile='.deps/alloc.TPo' \
depmode=tru64 /usr/bin/sh ../config/depcomp \
cc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src -I/usr/local/gnu/include
-O2 -c `test -f alloc.c || echo './'`alloc.c
source='amflock.c' object='amflock.o' libtool=no \
depfile='.deps/amflock.Po' tmpdepfile='.deps/amflock.TPo' \
depmode=tru64 /usr/bin/sh ../config/depcomp \
cc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src -I/usr/local/gnu/include
-O2 -c `test -f amflock.c || echo './'`amflock.c
source='debug.c' object='debug.o' libtool=no \
depfile='.deps/debug.Po' tmpdepfile='.deps/debug.TPo' \
depmode=tru64 /usr/bin/sh ../config/depcomp \
cc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src -I/usr/local/gnu/include
-O2 -c `test -f debug.c || echo './'`debug.c
source='dgram.c' object='dgram.o' libtool=no \
depfile='.deps/dgram.Po' tmpdepfile='.deps/dgram.TPo' \
depmode=tru64 /usr/bin/sh ../config/depcomp \
cc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src -I/usr/local/gnu/include
-O2 -c `test -f dgram.c || echo './'`dgram.c
cc: Warning: dgram.c, line 110: In this statement, the referenced type of the pointer
value len is unsigned int, which is not compatible with int because they differ
by signed/unsigned attribute. (ptrmismatch1)
if(getsockname(s, (struct sockaddr *)name, len) == -1) {
^
cc: Warning: dgram.c, line 292: In this statement, the referenced type of the pointer
value addrlen is unsigned long, which is not compatible with int. (ptrmismatch)
(struct sockaddr *)fromaddr, addrlen);
-^
source='error.c' object='error.o' libtool=no \
depfile='.deps/error.Po' tmpdepfile='.deps/error.TPo' \
depmode=tru64 /usr/bin/sh ../config/depcomp \
cc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src -I/usr/local/gnu/include
-O2 -c `test -f error.c || echo './'`error.c
source='file.c' object='file.o' libtool=no \
depfile='.deps/file.Po' tmpdepfile='.deps/file.TPo' \
depmode=tru64 /usr/bin/sh ../config/depcomp \
cc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src -I/usr/local/gnu/include
-O2 -c `test -f file.c || echo './'`file.c
source='fileheader.c' object='fileheader.o' libtool=no \
depfile='.deps/fileheader.Po' tmpdepfile='.deps/fileheader.TPo' \
depmode=tru64 /usr/bin/sh ../config/depcomp \
cc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src -I/usr/local/gnu/include
-O2 -c `test -f fileheader.c || echo './'`fileheader.c
source='match.c' object='match.o' libtool=no \
depfile='.deps/match.Po' tmpdepfile='.deps/match.TPo' \
depmode=tru64 /usr/bin/sh ../config/depcomp \
cc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src -I/usr/local/gnu/include
-O2 -c `test -f match.c || echo './'`match.c
source='protocol.c' object='protocol.o' libtool=no \
depfile='.deps/protocol.Po' tmpdepfile='.deps/protocol.TPo' \
depmode=tru64 /usr/bin/sh ../config/depcomp \
cc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src -I/usr/local/gnu/include
-O2 -c `test -f protocol.c || echo './'`protocol.c
source='regcomp.c' object='regcomp.o' libtool=no \
depfile='.deps/regcomp.Po' tmpdepfile='.deps/regcomp.TPo' \
depmode=tru64 /usr/bin/sh ../config/depcomp \
cc -DHAVE_CONFIG_H -I. -I. -I../config -I./../regex-src -I/usr/local/gnu/include
-O2 -c `test -f regcomp.c || echo './'`regcomp.c
source='regerror.c' object='regerror.o' libtool=no \
depfile='.deps/regerror.Po' tmpdepfile='.deps/regerror.TPo' \
depmode=tru64 /usr/bin/sh ../config/depcomp \
cc
