EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: RE: Setting option flags for building system libraries
From: "Jeff Hill" <[email protected]>
To: "'David Dudley'" <[email protected]>, <[email protected]>
Date: Tue, 22 Aug 2006 17:23:00 -0600
> When I run it, it says "The CA server's beacon address list was empty
> after initialization?"

Possible causes:

O you have a non-default configuration that results in an empty beacon
address list - see the ca reference man
O no network interfaces installed in this host
O issues with os dependent bits of osiSockDiscoverBroadcastAddresses -
possibly with the os dependent implementation of ifreq_size (). 

Jeff

> -----Original Message-----
> From: David Dudley [mailto:[email protected]]
> Sent: Tuesday, August 22, 2006 4:23 PM
> To: [email protected]
> Subject: Re: Setting option flags for building system libraries
> 
> Actually, if I had read Janet's excellent directions further (and with my
> glasses on this time...), I would have found the single variable I needed.
> 
> The build works without error now, building the .so files with no problem
> on 3.14.8.2, but can't pass the RTEMS or libCom/test directories on the
> CVS download.  Haven't worked on that problem yet....
> 
> I successfully built the sample application using makeBaseApp.pl, and it
> compiles and runs.
> When I run it, it says "The CA server's beacon address list was empty
> after initialization?", which I'm assuming is wrong.
> I can do a 'dbl' and I see a list of records, however.
> When I try to do a 'dbpr' on any of them, I get "dbNametoAddr failed", so
> I assume there is a problem.
> 
> But anyway - it didn't lock the machine up!
> 
> David
> 
> >>> Andrew Johnson <[email protected]> 08/22/06 4:58 PM >>>
> Hi David,
> 
> David Dudley wrote:
> >
> > 1. To build a relocatable library for libCom, I have to pass options
> > "-shared -fPIC" through to g++ when I'm creating the relocatable
> > library.  This works fine, and I can create and use the library sort
> > of successfully.  I'm still looking for the exact variable to set to
> > pass these values.  have tried setting about every variable in my new
> > "CONFIG.Common.netbsd-x86" file, and currently have it set in
> > COMPILER_LDFLAGS.  However, when I run gmake with these options
> > selected in  COMPILER_LDFLAGS, it will create a properly library, but
> > fails to create a proper executable.
> >
> > 2. To build an executable, I have to be sure NOT to pass the
> > "-shared" option through to g++.  I demonstrated that this works by
> > deleting the incorrectly build 'antelope' program that is linked
> > after the library is built, delete the "-shared" flag from my new
> > "CONFIG.Common.netbsd-x86" file and rerun gmake.  This will recreate
> > the antelope program, which appears to be functional.
> 
> Hmm, I think there may be a problem here which means you might not be
> able to create shared libraries for NetBSD.  Can I make sure I'm
> understanding your point first though:
> 
> 1. To compile code for a .so, you *must* pass '-shared' to the gcc or
> g++ command line when you compile the .c/.cc/.cxx file.
> 2. To compile code for an executable (and presumably for a lib.a file),
> you *must* *not* pass '-shared' to the gcc/g++ command line.
> 
> If those statements are both correct, I think you're going to have to
> disable the building of shared libraries since I believe we have no way
> to recompile a source file with different options to generate two
> different .o files from the same source.
> 
> You can disable building shared libraries by setting SHARED_LIBRARIES=NO
> in your CONFIG.Common.netbsd-x86 file.  I would recommend that you do
> that anyway for now and come back to the .so problem later.
> 
> > Looks like most of the Make files were done by jba (I'm taking that
> > to be Janet Anderson, I hope... She still doing work on this, or
> > anyone have a suggestion?
> 
> Yes, JBA is Janet Anderson <[email protected]> who is responsible for the
> build system.
> 
> David Dudley wrote:
> > Well, I'm sure it won't run correctly, but    ***IT COMPILES WITHOUT
> ERRORS***!
> 
> Congratulations!  I assume you ignored or disabled the .so builds to get
> to this point.
> 
> - Andrew
> --
> There is considerable overlap between the intelligence
> of the smartest bears and the dumbest tourists.
>    -- Yosemite National Park Ranger
> 



References:
Re: Setting option flags for building system libraries David Dudley

Navigate by Date:
Prev: Re: VCCT and CA sniffer Rolf Keitel
Next: Re: VME Bus Error handling on MVME3100 and 6100 boards Till Straumann
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Setting option flags for building system libraries David Dudley
Next: RE: Setting option flags for building system libraries David Dudley
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  2005  <20062007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·