Thanks!
I had tried "make -j 1" before, in various combinations, but it failed also.
This time, however, when I started afresh (to get the error message), it worked.
Twice.
"Make static" not being supported on Windows with VC++ is a bit of a problem for
me. No wonder that's where many of my problems have been. It looks like I'll
have to construct a static library on my own, after doing the make. I'll try:
cut-and-paste the list of .o files into my script
run the MS lib program to make a .lib from them
use that lib to link my program.
This is rather ugly, and such a script may not work on other Root releases, but
I hope it will get me going.
The fallback approach, which is where I was going, is to generate
a map on Linux and use it to determine precisely which .o-s are
needed, and just compile them. This has thorns....
That approach might actually resolve my problems on the supercomputer, too -- I
could build Root with a private copy of the X-windows headers, ignoring the link
of root that fails. Then construct a library as above and link my program with
it. While Root as a whole needs X-windows headers to compile and libraries to
link, my program uses no Root routine that needs them.
Again, thanks!
Tom Roberts
Bertrand Bellenot wrote:
> Hi Tom,
>
> The failure may come from make -j2. Could you try to use make (without
> any -jX)?
> or just retype make after the failure, or even type make -k to ignore
> the compilation errors...
>
> And FYI, "make static" is not supported on Windows with the MSVC++
> compiler.
>
> Cheers, Bertrand.
>
> Tom Roberts wrote:
>> This is root 5.24 being built on Windows Xp using MS VC++ Express
>> edition 8.0
>> SP1 via Cygwin's make. I am building root in order to link it
>> statically with my
>> program; all that the program uses directly are classes TFile,
>> TNtuple, and
>> TDirectory. I use the same build system on Mac OS X, Linux, and
>> Windows; root
>> 5.24 built fine on the Mac and 5.20 built fine on RedHat Linux 7.3
>> (yes, that's
>> very old; so old that newer versions of libraries won't compile on
>> it). I don't
>> think it matters, but Windows Xp SP3 is running in a VMware virtual
>> machine with
>> 2 CPUs and 1 GB RAM.
>>
>> For debugging, I have simplified the build as much as possible, but it
>> still
>> does not work:
>> (start with a new bash shell in a rxvt window, after setting up VC++)
>> (unpack the source tarball into C:/root and cd there)
>> ./configure
>> make -j 2
>> ... MANY lines omitted
>> bin/rmkdepend.exe -R -fcint/reflex/src/genmap/genmap.d -Y -w 1000 --
>> -nologo
>> -FIw32pragma.h -MD -GR -EHsc- -W3 -wd4244 -Iinclude -D_WIN32
>> -Icint/reflex/src/genmap -D__cplusplus --
>> cint/reflex/src/genmap/genmap.cxx
>> make: *** No rule to make target
>> `net/xrootd/src/xrootd/bin/xrdcp.exe', needed
>> by `bin/xrdcp.exe'. Stop.
>> make: *** Waiting for unfinished jobs....
>>
>> It also fails, in a different way, when I disable everything I can:
>> ./configure --disable-afs --disable-alien --disable-asimage
>> --disable-astiff
>> --disable-builtin-afterimage --disable-castor --disable-chirp
>> --disable-cint7
>> --disable-cintex --disable-clarens --disable-dcache --disable-exceptions
>> --disable-explicitlink --disable-fftw3 --disable-gdml --disable-gfal
>> --disable-g4root --disable-globus --disable-glite --disable-gsl-shared
>> --disable-krb5 --disable-ldap --disable-genvector --disable-mathmore
>> --disable-memstat --disable-minuit2 --disable-monalisa --disable-mysql
>> --disable-odbc --disable-opengl --disable-oracle --disable-pch
>> --disable-peac
>> --disable-pgsql --disable-pythia6 --disable-pythia8 --disable-python
>> --disable-qt --disable-qtgsi --disable-reflex --disable-rfio
>> --disable-roofit
>> --disable-rpath --disable-ruby --disable-sapdb --disable-shadowpw
>> --disable-shared --disable-soversion --disable-srp --disable-ssl
>> --disable-table
>> --disable-unuran --disable-winrtdebug --disable-xml --disable-xrootd
>> --disable-xft
>>
>>
>> Suggestions?
>>
>> Right now I'm going back to try 5.20....
>> For 5.20 the make succeeded, but "make static" fails because libpcre.a
>> and
>> libfreetype.a are not found; there are files libpcre.lib and
>> libfreetype.lib.
>> Fixing that apparent typo does not help, as there are zillions of
>> unresolved
>> externals like this:
>> G__Reflex.o : error LNK2019: unresolved external symbol
>> "__declspec(dllimport)
>> class std::basic_ostream<char,struct std::char_traits<char> > & __cdecl
>> Reflex::operator<<(class std::basic_ostream<char,struct
>> std::char_traits<char> >
>> &,class Reflex::PropertyList const &)"
>> (__imp_??6Reflex@@YAAAV?$basic_ostream_at_DU?$char_traits_at_D@std@@@std@@AAV12_at_ABVPropertyList@0@@Z)
>>
>> referenced in function "void __cdecl G__setup_memfuncReflex(void)"
>> (?G__setup_memfuncReflex@@YAXXZ)
>>
>> At one point I had similar results with 5.24 (make succeeds, "make
>> static" fails
>> as above).
>>
>> Any help would be appreciated.
>>
>>
>> BACKGROUND: What I am trying to do.
>>
>> I am trying to prepare a release of my program, G4beamline, such that
>> users can
>> be reasonably expected to build it. That means I must include all
>> non-system
>> library source, including Root (also coin3d, soxt, sowin, gsl, clhep,
>> and geant4
>> -- the source totals 480 MB). The only Root classes used directly are:
>> TFile,
>> TDirectory, and TNTuple.
>>
>> I expect the build system to work on the following OSs:
>> * Max OS X (Intel) 10.4, 10.5, 10.6 (Tiger, Leopard, Snow Leopard)
>> * Linux RedHat 7.3 (very old, this is for my binary distribution)
>> * Scientific Linux Fermi 3.0.9, 4.5, 5.3
>> * Windows Xp, Windows Vista, (Windows 7 eventually)
>> * Linux on a supercomputer (no X-windows, visualization, or shared
>> objects)
>>
>> All but the last two are working. BOTH of them very painful, and *ALL*
>> of my
>> problems are related to Root. It is all the more frustrating as in the
>> past I
>> have built root on Windows, but can't get it to work now (even when I
>> follow
>> the exact same procedure in my notes).
>>
>> In parallel I am considering abandoning Root, replacing it with HDF
>> (this will
>> require code to read HDF files in Root, as we will still analyze
>> results using
>> Root). HDF is much smaller than Root, supports everything the program
>> needs,
>> and doesn't bring all the baggage that is inherent in Root (graphics,
>> a C++
>> interpreter, ...).
>>
>>
>> Tom Roberts
>>
>
Received on Wed Dec 23 2009 - 22:50:06 CET