Hi Matt,
I have a solution to test. It is on the nanohttp_stream branch in ADCore and ADSupport.
It builds OK for me with both XML2_EXTERNAL=NO and XML2_EXTERNAL=YES on Centos7 and Centos8.
I have not tested that the MJPEG streaming and NDFileMagick actually work, just that it builds with no errors.
Hopefully Peter Heesterman can test it.
Mark
-----Original Message-----
From: Pearson, Matthew R. <pearsonmr at ornl.gov>
Sent: Wednesday, May 12, 2021 8:43 AM
To: Mark Rivers <rivers at cars.uchicago.edu>; Simon Rose <Simon.Rose at ess.eu>
Cc: tech-talk at aps.anl.gov
Subject: RE: Building ADSupport with external libxml2
Thanks Mark and Simon, that sounds like a good solution.
For the record I am using base 7.0.5. Although all my prior builds of ADSupport were done with base R3.14.12.6 and ADSupport<R1-5, so I never saw the issue before.
Cheers,
Matt
-----Original Message-----
From: Mark Rivers <rivers at cars.uchicago.edu>
Sent: Wednesday, May 12, 2021 7:53 AM
To: Pearson, Matthew R. <pearsonmr at ornl.gov>; Simon Rose <Simon.Rose at ess.eu>
Cc: tech-talk at aps.anl.gov
Subject: [EXTERNAL] Re: Building ADSupport with external libxml2
Hi Matt,
> It seems like there's been some custom changes to the xml2 packaged with ADSupport,
> so that now GraphicsMagick requires the use of the packaged xml2 and cannot build with the system xml2.
You are correct. This issue was introduced in ADSupport R1-5 in November 2018. It was done to extend nanohttp.c to handle MJPEG streams. Currently if you use WITH_GRAPHICSMAGICK=YES then you must use XML2_EXTERNAL=NO.
My goal is to allow the use of the system versions of libraries like XML2, JPEG, etc., so I think this is a bug that should be fixed.
I am working on a solution that moves the new version of nanohttp.c to a separate library with different function names, and change url.c in GraphicsMagick to use those new functions. That will allow it to co-exist with the standard version of libxml2.
Mark
________________________________
From: Tech-talk <tech-talk-bounces at aps.anl.gov> on behalf of Simon Rose via Tech-talk <tech-talk at aps.anl.gov>
Sent: Wednesday, May 12, 2021 1:51 AM
To: Pearson, Matthew R.; tech-talk at aps.anl.gov
Subject: Re: Building ADSupport with external libxml2
Hi Matt -
Which version of EPICS base are/were you using? There was an addition of the following line in base 7.0.5 (compared to 7.0.4.1):
WARN_CFLAGS_YES = -Wall -Werror-implicit-function-declaration
There were a few places in ADSupport (notably GraphicsMagick) that needed fixes due to this; it is possible that we missed some of them.
Cheers,
Simon
On 2021-05-11, 17:16, "Tech-talk on behalf of Pearson, Matthew R. via Tech-talk" <tech-talk-bounces at aps.anl.gov on behalf of tech-talk at aps.anl.gov> wrote:
Hi,
I've been attempting to build ADSupport (R1-9-1) with the following options on RHEL7/8:
XML2_EXTERNAL=YES
XML2_LIB=/usr/lib64/
XML2_INCLUDE=/usr/include/libxml2/
And that used to work, but it now fails with:
../url.c
../url.c: In function 'ReadURLImage':
../url.c:195:17: warning: implicit declaration of function 'xmlNanoHTTPFrameState' [-Wimplicit-function-declaration]
if ((xmlNanoHTTPFrameState(context) == Complete) || (xmlNanoHTTPFrameState(context) == Error))
^
../url.c:195:56: error: 'Complete' undeclared (first use in this function)
if ((xmlNanoHTTPFrameState(context) == Complete) || (xmlNanoHTTPFrameState(context) == Error))
^
../url.c:195:56: note: each undeclared identifier is reported only once for each function it appears in
../url.c:195:104: error: 'Error' undeclared (first use in this function)
if ((xmlNanoHTTPFrameState(context) == Complete) || (xmlNanoHTTPFrameState(context) == Error))
^
../url.c:200:15: warning: implicit declaration of function 'xmlNanoHTTPStreaming' [-Wimplicit-function-declaration]
if (!xmlNanoHTTPStreaming(context))
^
make[4]: *** [url.o] Error 1
It seems like there's been some custom changes to the xml2 packaged with ADSupport, so that now GraphicsMagick requires the use of the packaged xml2 and cannot build with the system xml2.
This build option works fine:
XML2_EXTERNAL=NO
(which is the default set in the areaDetector example CONFIG_SITE files).
In the past I have usually built ADCore and IOC applications with the system installed libxml2 (and jpeg, tiff etc), and we haven't relied on ADSupport that much (since we generally don't use GraphicsMagick).
What would be the recommended practice?
1) Build all areaDetector modules (including ADCore) against ADSupport (whether or not we need GraphicsMagick)
2) Build all areaDetector modules against system libraries, except ADSupport which would build against its own version of xml2 (but then an IOC that uses GraphicsMagick would be linking to different versions of the same library, which doesn't sound good).
I suppose 1) also has the advantage that the libraries packaged with ADSupport can be more easily versioned. Although, has anyone ever had problems with the Linux system libraries for XML2, TIFF, JPEG, etc?
Cheers,
Matt
- Replies:
- RE: Building ADSupport with external libxml2 Heesterman, Peter J via Tech-talk
- References:
- Building ADSupport with external libxml2 Pearson, Matthew R. via Tech-talk
- Re: Building ADSupport with external libxml2 Simon Rose via Tech-talk
- Re: Building ADSupport with external libxml2 Mark Rivers via Tech-talk
- RE: Building ADSupport with external libxml2 Pearson, Matthew R. via Tech-talk
- Navigate by Date:
- Prev:
RE: Building ADSupport with external libxml2 Pearson, Matthew R. via Tech-talk
- Next:
RE: Building ADSupport with external libxml2 Heesterman, Peter J via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
<2021>
2022
2023
2024
- Navigate by Thread:
- Prev:
RE: Building ADSupport with external libxml2 Pearson, Matthew R. via Tech-talk
- Next:
RE: Building ADSupport with external libxml2 Heesterman, Peter J via Tech-talk
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
<2021>
2022
2023
2024
|