Hi Marco,
The package ATLFAST was developped two years ago on HP-UX and LINUX.
It has been tested on most Unix systems. Some attempts have been made by
Valery Fine under NT. I followed the discussion between Sergey and
Valery a few weeks ago, but I see that Sergey had the good idea to move
to a platform for which
many more people can provide support today.
If somebody provides me with a working Makefile for NT, I will include
it
in the distribution set. I have ZERO time myself to investigate what
could be the problem.
One thing is sure. YOU SHOULD NOT HAVE REPLACED the EXTERN by extern.
I think that most of of your problems come from this change.
Rene Brun
mvl@nikhef.nl wrote:
>
> Hello everybody,
>
> It has already taken me some days to get the class TPythia to work on my
> PC. At first I thought that it would be my inexperience, but now I decided
> to that it couldn't be only that. So I decided to bring this up in
> roottalk. It's become a rather elaborate story, involving root, rootCINT,
> ATLFast and a Windows-specific 'problematic feature' (the space in
> "C:\Program Files"). Most of it is solved, but I do not know enough of
> libvraries, dlls, linkage and other stuff to solve the last one. So let's
> have a go at it (I am working on a Pentium PC, Windows NT 4.0, VC++ 5.0).
>
> First, I try the standard procedure:
> At the root prompt, I type:
> gSystem.Load("C:/Program Files/root/bin/Root_EGPythia.dll")
> The following error results:
> "The procedure entrypoint ?AppendPad@TObject@@QAEXPAD@Z could not be
> located in the dynamic link library Root_Base.dll"
>
> To get a fine example of the used of Pyhtia in a to-be-compiled program, I
> downloaded the ATLFast-example (from the root pages). Trying to compile the
> ATLFast-package at first prsented a lot of trouble. This is due to the
> installation of root in C:\Program Files. The space in the directory name
> is confusing when command line arguments to the compiler or linker are
> given. I have altered the make-files to prevent this problem, by inserting
> quotes at the appropiate places. So if anyone is interested in the
> windows-makefiles for ATLFast, please let me know.
>
> With the new makefile, tried: nmake -f makefile.win
>
> At compilation, the following warning is produced.
> ATLFast.cxx (187) Warning Cxxxx 'gATLFast' inconsistent dll lnkage. DLL
> export assumed
>
> By changing the EXTERN in line 187 (ATLFast.h) to "extern", this is solved.
>
> ----Intermezzo----
> This change automatically invokes rootcint at the next make-session. This
> produces some errors during the excution of rootcint and later on during
> compilation, therefore, I switched of the generation of dictionaries in the
> makefile, since versions of ATLFastCint.cxx and ATLFastgCint.cxx are
> included in the package.
> The errors are all produced by stdio.h and are all called "limitations".
> Also one error is generated by a preprocessor-statement. It says: # error
> ERROR: only Mac and Win32 target supported.
> The advice is given to use +p or -P or wahtever, but I can't find a way to
> insert this switch without generating an error (I also tried it directly
> from the command line). I am not sure whether this is all fatal or nor,
> because this type of warnings is also generated when using rootcint on the
> example program Hello.h.
> -------------------
>
> During linkage of libATLFast.dll another warning is generated. The warning
> has something to do with the global or local definition of gATLFast. This
> can be solved by including libATLFast.lib in the linking.
>
> However, the next error is generated by Linkage of libATLFastg.dll and I
> have found no way of solving it. The error is:
> libatlfastg.exp: error LNK2001: unresolved external symbol "class ATLFast *
> gATLFast" (?gATLFast@@3PAVATLFast@@A)
>
> I also tried including libatlfats.lib and libatlfastg.lib in the linkage,
> but it didn't work out. So what do I do wrong?
>
> Thanks for your attention, I hope some of this is helpfull for you, and
> that someone can help me.
>
> Greetings,
>
> Marco van Leeuwen
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:30 MET