I realized that I only need to link Root statically on Linux (for a
supercomputer that does not support shared objects); linking statically on
Windows was merely convenient. So I have changed my build process to link Root
using DLL-s on Windows, and to link statically on Linux and Mac OS X. On
Windows, I need to copy seven root DLL-s into my bin directory. This is now
working -- this is a much better approach, as I am not doing anything funky.
I had tried playing with constructing my own static library.
It worked first time on Mac OS X, but I could not get it to
work on Windows. I gave up once I realized I didn't need it.
Again, thanks!
Tom Roberts
Tom Roberts wrote:
> 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 Sun Dec 27 2009 - 03:56:26 CET