Re: Pythia6 problem on Mac OS X Tiger

Hi Mario,
I encountered this problem recently. It happened to me because of the following:
1. the new compiler g77 (I have 3.4.5 you have 3.4.4) puts NO underscore at the end of fortran common_block

    and puts ONE underscore at the end of fortran routines. 2. The root "configure" scripts tries to determine of how many underscores are in the libPythia.so for

    pythia6_common_block_address and respecting this it produces a special compilation option (flag) for the

    Pythia (like: -DPYTHIA6_DOUBLE_UNDERSCORE, -DPYTHIA6_SINGLE_UNDERSCORE, -DPYTHIA6_NO_UNDERSCORE)     This scripts assumes that the same rule is applied also for fortran routines. It works with previous compilers.

    However new g77 seems to change its behaviour and now they assign no underscore for common blocks and one (or two) underscores

    for routines. That is why to my mind the scripts produces a wrong option.
3. As a result TPythia6.cxx can not find a proper interface to these two functions:

    tpythia6_close_fortran_file
    tpythia6_open_fortran_file
4. There are two solutions at least:

    o) add a new option into configure script (one for common blocks, second for routines). This is an easy thing to do (I can do it if needed)

    o) just put by hand (or take from CVS head as suggested by Rene) the following patch into TPythia6.cxx:

# ifdef PYTHIA6_DOUBLE_UNDERSCORE
#  define tpythia6_open_fortran_file tpythia6_open_fortran_file__
#  define tpythia6_close_fortran_file tpythia6_close_fortran_file__
#  define pythia6_common_address pythia6_common_block_address__
# elif PYTHIA6_SINGLE_UNDERSCORE
#  define tpythia6_open_fortran_file tpythia6_open_fortran_file_
#  define tpythia6_close_fortran_file tpythia6_close_fortran_file_
#  define pythia6_common_address pythia6_common_block_address_
# else
# define pythia6_common_address pythia6_common_address
# define tpythia6_open_fortran_file tpythia6_open_fortran_file_
# define tpythia6_close_fortran_file tpythia6_close_fortran_file_
# endif

lines after else were missing for this configuration. This is not really a nice solution but it can solve your problem temporarly. Hope this can help you,
Regards, Dmitry

Mario Kadastik wrote:

> maku:/Applications/root/lib toruonu$ nm libPythia6.dylib |grep tpythia
> 00001170 T _tpythia6_close_fortran_file_
> 000010f4 T _tpythia6_open_fortran_file_
> maku:/Applications/root/lib toruonu$ nm libPythia6.so |grep tpythia
> 00001190 T _tpythia6_close_fortran_file_
> 00001114 T _tpythia6_open_fortran_file_
>
> so the relevant functions are there... Am I the idiot here or why
> does g++ just not work?
>
> Mario
>
> On Dec 22, 2005, at 12:47 AM, Edmond Offermann wrote:
>
>> try "nm"
>>
>> --- Mario Kadastik <mario.kadastik_at_cern.ch> wrote:
>>
>>> Hello Rene,
>>>
>>> Well the files are in tarball, but you have to compile them to make
>>> libPythia6.so and libPythia6.dylib. That's exactly what I did and it
>>>
>>> also works just fine in CINT however it doesn't work when I try to
>>> compile it.
>>>
>>> The versions I use are:
>>> maku:~/Downloads/pythia6 toruonu$ g77 --version
>>> GNU Fortran (GCC) 3.4.4
>>> Copyright (C) 2004 Free Software Foundation, Inc.
>>>
>>> GNU Fortran comes with NO WARRANTY, to the extent permitted by law.
>>> You may redistribute copies of GNU Fortran
>>> under the terms of the GNU General Public License.
>>> For more information about these matters, see the file named COPYING
>>> or type the command `info -f g77 Copying'.
>>> maku:~/Downloads/pythia6 toruonu$ gcc --version
>>> powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 20041026 (Apple Computer,
>>>
>>> Inc. build 4061)
>>> Copyright (C) 2004 Free Software Foundation, Inc.
>>> This is free software; see the source for copying conditions. There
>>>
>>> is NO
>>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>>> PURPOSE.
>>>
>>> that's so as g77 latest release is for 3.4.4 after that there is only
>>>
>>> fortran f95 and using that will not compile pythia as it fails with
>>> missing symbols itime and idate ...
>>>
>>> And as I don't use gcc-4.0.3 then what else could be the problem? I
>>> tried reorganizing the library reference on the command line hoping
>>> it would cure the unresolved symbol, but no... is there a way to
>>> check which symbols are in which libraries in Mac OS X so that I
>>> could check if they are in the libraries?
>>>
>>> Mario
>>>
>>> On Dec 21, 2005, at 8:20 PM, Rene Brun wrote:
>>>
>>>> Mario,
>>>>
>>>> I do not understand your problem. The files that you quote as
>>>> missing when linking are provided in the tar file.
>>>> May be you are hitting the same problem that was reported recently
>>>
>>>
>>>> by Dmitry Naumov when compiling with the latest gcc4.0.3 compiler
>>>> (something to do with underscores).
>>>> If indeed you use this compiler, you can start from the CVS head
>>>> where this problem has been fixed. You can take pythia6/src/
>>>> TPythia6.cxx
>>>> only.
>>>>
>>>> Let me know
>>>>
>>>> Rene Brun
>>>>
>>>> On Wed, 21 Dec 2005, Mario Kadastik wrote:
>>>>
>>>>> Rene Brun wrote:
>>>>>
>>>>>> Mario,
>>>>>> Look at http://root.cern.ch/root/Install.html
>>>>>> and section "Pythia generator:
>>>>>> Take the tar file pythia6.tar.gz. It contains all the necessary
>>>>>> files
>>>>>> to compile on all machines.
>>>>>
>>>>>
>>>>> that's exactly where I took it from :) and that's the
>>>>> makePythia.macosx script I'm running in my previous e-mail and as
>>>>
>>>
>>>>> you can see it compiles nicely. I can also run my code in root,
>>>>> but I can't compile it due to the linking errors I wrote about.
>>>>> But I would like to compile as I have a lot of datasets against
>>>>> which I'd like to run my code and running it from command line
>>>>> using arguments is a lot more convenient.
>>>>>
>>>>> Mario
>>>>>
>>>
>>>
>>
Received on Thu Dec 22 2005 - 07:48:13 MET