Builds fail on Cygwin

Bug #1438334 reported by Andrew Johnson
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
EPICS Base
Fix Released
High
Ralph Lange

Bug Description

Cygwin builds of 3.15 (and 3.16) have been failing on Jenkins for several months, in the src/ioc/db/test directory.
  https://jenkins.aps.anl.gov/view/EPICS%20Base/job/epics-base-3.15-cyg64/
I have seen the same failures in my personal builds on Cygwin, so this isn't a Jenkins-specific problem.

This should be fixed before the 3.15.2 release since Cygwin is an officially supported platform, although I generally discourage people from using it unless they have no choice, for performance reasons.

Revision history for this message
Ralph Lange (ralph-lange) wrote :

Confirmed.

I set up the toolchain for Cygwin (reluctantly), and tried to find an obvious reason, which failed.
The first failing build has a bazillion source changes, so I will have to setup a "blame" job (Darcs speech - how does Bazaar call that?) to find the culprit.

Assign to me, but not a show-stopper for the -pre1.

Changed in epics-base:
status: New → Confirmed
assignee: nobody → Ralph Lange (ralph-lange)
Revision history for this message
Ralph Lange (ralph-lange) wrote :

Running 'bzr bisect' manually - can't get the script-driven variant to work under cygwin.

Revision history for this message
Ralph Lange (ralph-lange) wrote :

Worst case scenario: there is more than one issue, and they are overlapping in time (=commits). So far I have seen two different failure modes.
I am trisecting now.

Summary:
Revision 12625 changed the build from successful to failure pattern 1.
Revision 12639 changed the build from failure pattern 1 to failure pattern 2 (current).

Pattern 1 occurs earlier in the build than pattern 2.
So it seems that revision 12639 fixed the issue creating pattern 1 (it is labeled "Fix Windows builds" after all).
Pattern 2 appeared somewhere between 12625 and 12639.

Revision history for this message
Ralph Lange (ralph-lange) wrote :

Revision 12625 was introducing the bug (which was hidden until 12639 by another issue introduced by 12625).

When building shared libraries on Windows, the DLL stub library is created as a secondary product by the linker when it creates the DLL.
Since the same LIBNAME variable is used in both static and shared builds, in the shared case a (static) build rule was established for the DLL stub library (it has the same name as the static library in the static build case).
So all Windows builds were creating the DLL stub twice: once (wrongly) following the static build rule, once (rightly) as a side product of the shared build. The order of these two linker calls determined if the wrong or the right product was overwritten.

As a side effect of revision 12625, that order was switched on Cygwin builds, so that the regular static libraries were installed as DLL stub libraries, leading to the build failure complaining about duplicate symbols.

Fixed by filtering out the DLL stub names from the set of targets that the static build rule is created for and adding an empty recipe for (not) creating the DLL stub in the shared build.

Changed in epics-base:
status: Confirmed → Fix Committed
Andrew Johnson (anj)
Changed in epics-base:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.