static build fails on HPUX

Bug #541250 reported by Jeff Hill
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
EPICS Base
Won't Fix
Wishlist
Andrew Johnson

Bug Description

From Chris Slominski,

I have built EPICS 3.14.7 for both linux-x86 and hpux-parisc. I can build a Linux client successfully using either the static or dynamic libraries. On the HP system, I can build with the dynamic libraries, but not the static. I get linker errors stating that "tcpiiu::operator new(unsigned long)" and "oldSubscription::operator new(unsigned long)" are undefined. I looked through the code for "tcpiiu::operator new(unsigned long)" and indeed found it in the class definition, but did not find an implementation. I did find an implementation for "tcpiiu:: operator new(size_t, tsFreeList<class tcpiiu,32,epicsMutexNOOP> &)". I am confused why the behavior of the linker differs from static and dynamic build. Any ideas?

Additional information:
The intent was to declare these new operators private to prevent accidental use of compiler generated defaults.

OS: HP-UX

Version: R3.14.7

Original Mantis Bug: mantis-208
    http://www.aps.anl.gov/epics/mantis/view_bug_page.php?f_id=208

Tags: 3.14 3.14.7 build
Revision history for this message
Jeff Hill (johill-lanl) wrote :

From Ralph Lange,

I'm not sure if building static on HP is something that ever worked. Did I write something about that in the .../doc/README file? I don't remember.

What you're seeing is probably a method that's never used, so with dynamic linking the linker never searches for it and generates no error. With static linking, the linker has to find and bind everything that is defined at compile time, so it barks about the missing implementation. I'm not sure about this special case, but there is a technique to keep the compiler from generating default constructors that involves defining them private and not provide implementations. Maybe the HP static build is not capable of handling such situations. Could be a different thing in your case, though.

Anyway - do you have to build it statically? Building statically on HP always generated a lot of trouble, so if you're not forced to have a static build, just do it dynamically. Or move to Linux. EPICS won't support HP much longer (way too much effort for way to few remaining users).

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

It turned out (in a later communication) that Chris is using HP-UX 11.11 - a version of HPSUX that was never actively supported for and by EPICS Base. We do not even have such a system running here at BESSY, so I won't be able to do any compilation or tests.

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

My assumption was wrong.

Same thing happens under HP-UX 11.00:

aCC -o catime -Wl,-a,archive -L../../../lib/hpux-parisc/ -AA -mt -Wl,+b/net/unix/csr-home/lange/work/epics/APS/epics/base/3-14-X/lib/hpux-parisc:/opt/epics/R3.14.7/base/3-14-7-0/lib/hpux-parisc,+s catimeMain.o catime.o -lca -lCom -Wl,-a,default -lm
/usr/ccs/bin/ld: Unsatisfied symbols:
   static tcpiiu::operator new(unsigned long) (first referenced in ../../../lib/hpux-parisc//libca.a(tcpiiu.o)) (code)
   static oldSubscription::operator new(unsigned long) (first referenced in ../../../lib/hpux-parisc//libca.a(oldSubscription.o)) (code)
make[3]: *** [catime] Error 1

Looks as if I'm back in the game here ...

Revision history for this message
Andrew Johnson (anj) wrote :

HP-UX no longer supported by EPICS.

Revision history for this message
Andrew Johnson (anj) wrote :

R3.14.10 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.