the same problem happened with 5.13.04 .
i sent the makelog to another directory, and you can see what's
happening here:
http://minos.phy.tufts.edu/glocke/rootstuff/mkinstalog_1
when i did 'make cintdlls' again, the response was as one would want,
telling me that i had already done this step, whihc i did right before
the problem appeared...
this is a 'win32' configured build.
this time i copied the pre-install directory before 'make install' so
i should be able to try and fix the problem without making the whole
thing over again...
what's going on here?
looking at the root log, it seems to know where the $DESTDIR is, the
first indication of a problem comes when it tries to delete some of
the source files and then install the tutorials:
"
Installing misc docs in /c/Root
rm: cannot remove directory `/c/Root/mytmpinstall/root/zip': Directory not empty
Installing tutorials in /c/Root/tutorials
cp: cannot stat `tutorials/*': No such file or directory
Installing tests in /c/Root/test
cp: cannot stat `test/*': No such file or directory
"
it seems to me that it does know where $DESTDIR is but it doesn't seem
to know where $INSTALLDIR is maybe?
i am workign to find a solution, but this is agonizing, after all the
trouble i've had getting this to build in the first place...
:\
- george
On 11/9/06, George Locke <georgelocke.roottalk_at_gmail.com> wrote:
> thanks go to axel naumann for his very helpful advice up till this point.
>
> after his last reply, the only problems i had were to do with
> incompatible header files (TUUID.cxx was calling highpart and lowpart
> but these weren't recognized; a bunch of redefinitions of various...).
> i downloaded the latest SDK from microsoft and that solved these
> problems.
>
> Actually, everything looked great, the main make worked, the make
> cintdlls worked, but the 'make install' command resulted in deleting
> everything!!!! what the hell is going on?
>
> unfortunatley, the makelog was deleted too. only the empty
> directories 'cint' and 'zip' were left!! no installation, no
> nothing!!!! AG!!
>
> here are the main makelog and the make cint dlls log, in case they're
> of use/interest.
> main make log: http://minos.phy.tufts.edu/glocke/rootstuff/mymakelog11-8_8
> make cintdlls log: http://minos.phy.tufts.edu/glocke/rootstuff/mkcintlog11-9_1
>
> (root ver 5.13.02, windows 2000 5.00.2195 Service Pack 4 )
>
> i'm going to download 5.13.04 and start over, but goddamn that
> incredibly annoying!
>
> - George
>
> On 11/8/06, Axel Naumann <Axel.Naumann_at_cern.ch> wrote:
> > Hi George,
> >
> > cygwin has it's own program called link, and it's in the way. Just do
> > mv /usr/bin/link.exe /usr/bin/link_cyg.exe
> > and it should work.
> >
> > Axel.
> >
> > George Locke wrote:
> > > [dammit i keep sending these directly to axel instead of to the list.
> > > sorry for spamming your inbox axel, you've been a great help]
> > >
> > > I was able to solve the problem of not finding a .h file (by changing
> > > some system variables again), but now there is a linking problem.
> > >
> > > here's the makelog:
> > > http://minos.phy.tufts.edu/glocke/rootstuff/mymakelog11-7_3
> > >
> > > after successfully creating object files for building, rmkdepend, the
> > > install crashes before actually creating rmkdepend. the first error
> > > that i see is after the object builds and i'll just include the rest
> > > of the log from there:
> > > "
> > > build/win/ld.sh -nologo -ignore:4049,4075,4217,4221 -incremental:no
> > > -o bin/rmkdepend.exe build/rmkdepend/cppsetup.o
> > > build/rmkdepend/ifparser.o build/rmkdepend/include.o
> > > build/rmkdepend/main.o build/rmkdepend/parse.o build/rmkdepend/pr.o
> > > build/rmkdepend/mainroot.o
> > > link: invalid option -- n
> > > Try `link --help' for more information.
> > > Running build/win/compiledata.sh
> > > Making include/compiledata.h
> > > bin/rmkdepend.exe -R -fcint/src/g__cfunc.d -Y -w 1000 -- -nologo
> > > -Ibuild/win -FIw32pragma.h -FIsehmap.h -MD -EHa -Iinclude --
> > > cint/src/g__cfunc.c
> > > make: bin/rmkdepend.exe: Command not found
> > > make: *** [cint/src/g__cfunc.o] Error 127
> > > "
> > >
> > > looks to me like the error is happening somewhere inside this
> > > build/win/ld.sh file (described as "Simple interface to LINK,
> > > tansforming -o <exe> to -out:<exe> and unix pathnames to windows
> > > pathnames"), but i'm not sure where :\ i can't find anywhere that has
> > > a -n option to a link command.
> > >
> > > regards,
> > > George
> > >
> > > On 11/7/06, Axel Naumann <Axel.Naumann_at_cern.ch> wrote:
> > >> OK, saw your mail too late. Glad it works.
> > >> Axel.
> > >>
> > >> George Locke wrote:
> > >> > well,
> > >> >
> > >> > cl.exe was couldn't find a DLL (mspdb80.dll) ; i put the path to it
> > >> > into PATH environmental variable and now cygwin outputs some msg with
> > >> > the version number, copyright info etc...
> > >> >
> > >> > the command unset VS_UNICODE_OUTPUT ; cl.exe 2>&1 | awk '{ if (NR==1)
> > >> > print $8 }'
> > >> > now outputs the version number of cl.exe, 14.000.5......
> > >> >
> > >> > so this certainly was gumming up the works in a major way! thanks
> > >> > very much for helping to uncover this, admittedly basic, problem.
> > >> > hopefully next time i'll know what kinds of things to look fro and be
> > >> > able to fix this kind of thing on my own.
> > >> >
> > >> > there was a missing header file which i'm adding. i'll certainly come
> > >> > running back if i find something else i can't fix on my own.
> > >> >
> > >> > THANKS AGAIN!!!
> > >> >
> > >> > regards,
> > >> > george
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> >
> > >> > On 11/7/06, George Locke <georgelocke.roottalk_at_gmail.com> wrote:
> > >> >> ---------- Forwarded message ----------
> > >> >> From: George Locke <georgelocke.roottalk_at_gmail.com>
> > >> >> Date: Nov 7, 2006 10:14 AM
> > >> >> Subject: Re: [ROOT] installing root from source using visual C++
> > >> >> To: Axel Naumann <Axel.Naumann_at_cern.ch>
> > >> >>
> > >> >>
> > >> >> no output following "cl.exe" :( as i said which cl.exe returns the
> > >> >> correct address
> > >> >>
> > >> >> no response to "unset VS_UNICODE_OUTPUT ; cl.exe 2>&1 | awk '{ if
> > >> >> (NR==1) print $8 }'"
> > >> >>
> > >> >> which cut returns /usr/bin/cut
> > >> >> which awk returns /usr/bin/awk
> > >> >>
> > >> >> i am investigating whether awk is working at all, when i
> > >> >> confirm/disconfirm that a hello world program works i'll let you know.
> > >> >>
> > >> >> once again, thanks a lot for you help.
> > >> >>
> > >> >> - george
> > >> >>
> > >> >>
> > >> >> On 11/7/06, Axel Naumann <Axel.Naumann_at_cern.ch> wrote:
> > >> >> > Hi George,
> > >> >> >
> > >> >> > George Locke wrote:
> > >> >> > > "Also, please don't mix the
> > >> >> > >> cygwin and the dos shell builds - you should probably always
> > >> use the
> > >> >> > >> cygwin shell for now, as it's better understood."
> > >> >> > > I hope i understand you to mean that i should 'make' in cygwin not
> > >> >> > > DOS, but i'll be creating a program that runs natively in
> > >> windows and
> > >> >> > > will make nice with msvc.
> > >> >> >
> > >> >> > That's correct, the aim is to call MSVC from within cygwin, to
> > >> build a
> > >> >> > native windows program.
> > >> >> >
> > >> >> > > rather then messing with making clean or distclean, i'm
> > >> deleting the
> > >> >> > > entire directory between builds, just to be extra sure that things
> > >> >> are
> > >> >> > > raelly clean.
> > >> >> >
> > >> >> > Fine.
> > >> >> >
> > >> >> > > typing in the command,
> > >> >> > > "
> > >> >> > > ( unset VS_UNICODE_OUTPUT ; cl.exe 2>&1 | \
> > >> >> > > awk '{ if (NR==1) print $8 }' | \
> > >> >> > > cut -d'.' -f1 )
> > >> >> > > "
> > >> >> > > i get no response.
> > >> >> >
> > >> >> > That's bad, abnd probably the reason why your build is failing. What
> > >> >> > does "cl.exe" print?
> > >> >> > What does "which awk" print?
> > >> >> > What does
> > >> >> > unset VS_UNICODE_OUTPUT ; cl.exe 2>&1 | awk '{ if (NR==1) print
> > >> $8 }'
> > >> >> > print?
> > >> >> > And finally "which cut"?
> > >> >> >
> > >> >> > Cheers, Axel.
> > >> >> >
> > >> >>
> > >> >
> > >>
> > >
> >
>
Received on Thu Nov 09 2006 - 18:01:24 MET