[Bioc-devel] Troubles with Windows build
hp@ge@ @end|ng |rom |redhutch@org
Wed Sep 11 18:42:24 CEST 2019
On 9/11/19 07:38, Ulrich Bodenhofer wrote:
> Dear colleagues,
> I have two issues with the Windows BUILD BIN of our 'msa' package. (to
> my horror, I figured out that the first problem has existed for quite a
> while; I am deeply sorry for that!)
> The main problem can be seen on
> It seems that something is wrong with the file
> src/ClustalOmega/src/exceptions4c/e4c_lite.o. Since it does not seem to
> me that e4c_lite.c is freshly compiled (I may be wrong in this point)
> and based on a StackOverflow post
> ), I have the impression that the build system might still have an on
> old version of some .o files. I can hardly imagine this, but it would
> explain the problem. To be frank, I am quite lost and have no idea what
> else could be the problem. Any hint is gratefully appreciated!
On our Windows servers the BUILD BIN stage uses the following compound
command to produce the binary package:
rm -rf msa.buildbin-libdir && mkdir msa.buildbin-libdir &&
C:\Users\biocbuild\bbs-3.10-bioc\R\bin\R.exe CMD INSTALL
--merge-multiarch --build --library=msa.buildbin-libdir msa_1.17.0.tar.gz
(Note that you can see this command at the top of the details page for
As you can see, we use --library=msa.buildbin-libdir to install to a
freshly created folder created at the beginning of the command. Command
components are chained with && to make sure that it will not proceed
further if one component fails so the 'R CMD INSTALL' component won't
run if for example 'rm -rf msa.buildbin-libdir' fails which guarantees
that we start with a fresh folder.
I think this looks indeed like a leftover/stale .o file but I think the
file is in the source tarball produced by the BUILD stage
(msa_1.17.0.tar.gz). If you look at your cleanup.win script, it doesn't
remove the stuff in src/ClustalOmega/src/exceptions4c/ so I think what
happens is that at the end of compilation the folder contains all the
*.o files for the 64-bit arch and these files get included in the source
tarball. Then the BUILD BIN stage choke on these files during the
'install for i386' step.
'diff cleanup cleanup.win' actually shows many differences between the 2
scripts. You might want to review them closely as it looks like some of
them are not intended.
> The second issue: the 'msa' package integrates multiple other open
> source packages in one shared library. In order to to so, it uses the
> 'ar' tool to compile static libraries of the individual packages and
> then combines them to a shared library.
AFAIK, 'ar' stands for "archive". It doesn't compile anything, it only
bundles things in one single *static* (not shared) library (.a file).
> This has always worked fine, and
> on the Bioconductor build servers, too. Now it seems I can no longer run
> the binary build on my Windows system. My Windows makefiles refer to the
> '$(AR)' variable, but it seems this variable is not correctly expanded
> to the actual location of the 'ar' tool (in Rtools 35, it is not in
> Rtools\bin, but in Rtools\mingw_(32|64)\bin) . Any thoughts on this?
Don't know. You might want to try SO or R-devel for this one.
> Thank you very much in advance and best regards,
> Bioc-devel using r-project.org mailing list
Program in Computational Biology
Division of Public Health Sciences
Fred Hutchinson Cancer Research Center
1100 Fairview Ave. N, M1-B514
P.O. Box 19024
Seattle, WA 98109-1024
E-mail: hpages using fredhutch.org
Phone: (206) 667-5791
Fax: (206) 667-1319
More information about the Bioc-devel