[Phylobase-devl] Compilation woes

Brian O'Meara omeara.brian at gmail.com
Tue Aug 5 20:17:21 CEST 2008 

It appears that the issue (or at least one issue) is a change of  
behavior of gcc in the newest version (4.3.1). Many standard C++  
library include files have been edited down to remove some things, so  
code that used to compile with the old header files are now missing  
some items (which can then be added in). [You'd think a standard  
header would have been standardized before now, but anyway]. More info  
is at http://gcc.gnu.org/gcc-4.3/porting_to.html . I think the NCL may  
need to be updated to work (it will compile under gcc 4.0 but not  
4.3), then phylobase should work.

Incidentally, the person who found this was Jon Auman, NESCent's  
sysadmin, when he was investigating what info I'd need from R-Forge to  
replicate their build environment. It's even more impressive when you  
find out he's not really an R or C programmer.

Brian


On Aug 4, 2008, at 8:30 AM, David Orme wrote:

> Hi everyone,
>
> Just to show that I am following the development - even if my
> contributions have been negligible!
>
> I think there is a great demand (extrapolating from Silwood,
> admittedly) for a more comprehensive function for reading nexus. The
> ape version has recently seen some changes that have cause no end of
> woes here, particularly problems with node labels. NCL is a killer
> feature and, recognising that these aren't trivial problems to solve,
> it would be a shame to see it branched. The package would get
> immediate uptake by code developers if it included a robust and stable
> nexus reader.
>
> Cheers,
> David
>
> On 4 Aug 2008, at 07:07, Peter Cowan wrote:
>
>> Hi all,
>>
>> I can't say that I have any special insight into the current
>> compilation issues.  Last time we went through this Stephan  
>> eventually
>> emailed me the R code that runs the package building.  So I do know
>> that a fresh copy of the SVN directory is made into a temporary
>> directory.  So I would be very surprised if the issue was related to
>> build products remaining.
>>
>> There seem to be a lot of configuration files under version control  
>> in
>> the top NCL folder.  A quick look at the SourceForge version shows
>> that they have fewer files.  I do think that at least some of these
>> configure files are auto created.  Perhaps we should pare down to  
>> only
>> the necessary files.
>>
>> As for the immediate future of NCL, I think it's going to be a killer
>> feature of the package.  However, so far it has consumed a lot of
>> developer time just trying to get it to build properly.  At least on
>> my part that is due to a lack of expertise with makefiles and C++ in
>> generally, perhaps this could be solved by contacting the NCL
>> developers?  I have also had frustrating experiences using the NCL
>> commands.  I sent an email regarding this experience previously to  
>> the
>> list.  I suspect that the performance issues will easily overcome.   
>> My
>> vote would be, if NCL is preventing successful building and thus
>> adoption of the package we should consider separating it, perhaps  
>> into
>> a branch.  I think there is a way for us to build multiple version of
>> the package see the "distr - S4 classes for distributions" package.
>>
>> My 2 cents
>>
>> Peter
>>
>> On Sun, Aug 3, 2008 at 9:49 PM, Steve Kembel <skembel at berkeley.edu>
>> wrote:
>>> Hi Brian,
>>>
>>>> Thanks for looking into this, Steve and Ben. If it is just a matter
>>>> of old files not being rewritten properly, this should be able to  
>>>> be
>>>> taken care of in the Makefile (effectively, make clean first). I'll
>>>> check it out some more.
>>>
>>> I'm not 100% sure about this. The install errors I get in Linux are
>>> not very reproducible, but that's my guess. For example I got a very
>>> similar error to the R-Forge linux build errors the first time I
>>> tried
>>> to build, but then slightly different errors on subsequent attempts,
>>> and no errors with a fresh copy of the code.
>>>
>>> A few more things about this:
>>> -make clean doesn't actually seem to work properly, there isn't a
>>> clean action defined in the ncl makefile, maybe this is part of the
>>> problem.
>>> -there is a script pkg/cleanup that gets rid of a lot of the
>>> accumulated files. I don't know if this could be incorporated into
>>> the
>>> make clean action. I missed this until now but I think this is
>>> something that Thibaut wrote to get phylobase to compile on  
>>> linux_x64
>>> a long while back. The message in which he describes it was pre-R-
>>> Forge so I'm including a copy of the text below. Sounds like part of
>>> the problem is indeed files not being deleted and messing up
>>> subsequent builds.
>>> -if i build the package from a clean copy of the code, the following
>>> files are left behind.
>>> steve at pundit:~/code/phylobase$ svn status
>>> ?      pkg.Rcheck
>>> ?      phylobase.Rcheck
>>> ?      phylobase_0.3-1.tar.gz
>>> ?      pkg/config.log
>>> ?      pkg/config.status
>>> ?      pkg/src/phylobase.so
>>> ?      pkg/src/Makevars
>>> ?      pkg/src/RcppSrc/libRcpp.a
>>> ?      pkg/src/ncl/config.log
>>> ?      pkg/src/ncl/config.status
>>> ?      pkg/src/ncl/stamp-h1
>>> ?      pkg/src/ncl/libtool
>>> ?      pkg/src/ncl/configure.lineno
>>> ?      pkg/src/ncl/Makefile
>>> ?      pkg/src/ncl/ncl/.deps
>>> ?      pkg/src/ncl/ncl/Makefile
>>> ?      pkg/src/ncl/ncl/.libs
>>> -if I then run the cleanup script, the following files are still
>>> left:
>>> steve at pundit:~/code/phylobase/pkg$ svn status
>>> ?      src/ncl/config.log
>>> ?      src/ncl/config.status
>>> ?      src/ncl/stamp-h1
>>> ?      src/ncl/libtool
>>> ?      src/ncl/configure.lineno
>>> ?      src/ncl/Makefile
>>> ?      src/ncl/ncl/.deps
>>> ?      src/ncl/ncl/Makefile
>>>
>>> Hope this helps. I definitely agree about the value of having NCL in
>>> phylobase, let's see if we can sort out these issues.
>>>
>>> Steve
>>>
>>> Begin forwarded message:
>>>
>>>> From: Thibaut Jombart
>>>> Date: February 13, 2008 9:16:53 AM PST
>>>> To: phylobase-devel at nescent.org
>>>> Subject: Re: [phylobase-devel] 64bits compilation troubles: IT  
>>>> WORKS
>>>>
>>>> Ben Bolker wrote:
>>>>
>>>>> OK, but ...
>>>>>
>>>>> I thought your last e-mail said that even hacking -fPIC into
>>>>> the Makefile didn't work.  I think "we" should first figure out
>>>>> if we can get it to build with a hacked Makefile, then figure
>>>>> out how to make the Makefile get constructed properly.
>>>>> (At worst, that might allow us to make a 64-bit binary
>>>>> to post on the web page, although fixing this properly
>>>>> would certainly be better.)
>>>>>
>>>>> I was guessing that ./configure --with-pics would
>>>>> work, but you tried that ...
>>>>>
>>>>> I think we might also be able to shove it into the
>>>>> automake flags somewhere ...
>>>>>
>>>>> Ben
>>>>>
>>>> Hi people,
>>>>
>>>> So I now have phylobase installed on my 64bits laptop. Yet, it does
>>>> not answer how we will generally fix the problem.
>>>> In fact, hacking the src/ncl/configure file indeed works, but  
>>>> didn't
>>>> for the following reason. It seems that .o objects are compiled  
>>>> only
>>>> when they do not already exist. If then do, then all what is done  
>>>> is
>>>> linking, and so the hack was not effective. So, this works for me:
>>>> 1) first run the cleanup script to override stuff like .o files.
>>>> 2) modify the configure script like follows:
>>>> (starting from line 20560)
>>>>
>>>>         CXXFLAGS_WARNINGS="$CXXFLAGS_WARNINGS"
>>>>         CXXFLAGS_OPTIM_SPEED="-O3 -ffast-math"
>>>>         CXXFLAGS_OPTIM_SPEED="-O3 -ffast-math"
>>>>         CXXFLAGS_OPTIM_SIZE="-Os -ffast-math"
>>>>         # modif by Thibaut
>>>>         CXXFLAGS_USE_FPIC="-fPIC"
>>>>     fi
>>>>     case "$build_os" in
>>>>         darwin*) CXXFLAGS_WARNINGS="$CXXFLAGS_WARNINGS -Wno-long-
>>>> double";;
>>>>         *);;
>>>>     esac
>>>> fi
>>>> if test "x$CXXFLAGS_OPTIM_SIZE" = "x"; then
>>>>     CXXFLAGS_OPTIM_SIZE=$CXXFLAGS_OPTIM_SPEED
>>>> fi
>>>>
>>>> CXXFLAGS="$CXXFLAGS $CXXFLAGS_OPTIM_SPEED $CXXFLAGS_WARNINGS
>>>> $CXXFLAGS_USE_FPIC"
>>>>
>>>> 3) run R CMD INSTALL (only warnings)
>>>>
>>>> Cheers,
>>>>
>>>> Thibaut.
>>>
>>> _______________________________________________
>>> Phylobase-devl mailing list
>>> Phylobase-devl at lists.r-forge.r-project.org
>>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/phylobase-devl
>>>
>> _______________________________________________
>> Phylobase-devl mailing list
>> Phylobase-devl at lists.r-forge.r-project.org
>> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/phylobase-devl
>
> _______________________________________________
> Phylobase-devl mailing list
> Phylobase-devl at lists.r-forge.r-project.org
> https://lists.r-forge.r-project.org/cgi-bin/mailman/listinfo/phylobase-devl

More information about the Phylobase-devl mailing list