pugixml and ports-gcc

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

pugixml and ports-gcc

Jeremie Courreges-Anglas-2

Hi,

filezilla fails to build at least on powerpc and sparc64:

  http://build-failures.rhaalovely.net/powerpc/2019-02-04/net/filezilla.log
  http://build-failures.rhaalovely.net/sparc64/2019-03-04/net/filezilla.log

--8<--
checking whether pugixml has been compiled with long long support... no
configure: error: pugixml system library has been compiled without long long support
-->8--

We have a local patch that prevents cmake from turning on long long
(C++11) support.  I guess the diff was needed to avoid a failure with
cmake-3.1.x and/or base-gcc, back in 2015.

If I remove our local patch, cmake-3.10.2 and ports-gcc happily build
a library with long long support activated.  base-clang builds aren't
affected (long long support by default).

check_sym reports and proposed diff below:

check_sym on sparc64
--8<--
billy /usr/ports/pobj/pugixml-1.7/fake-sparc64$ /usr/src/lib/check_sym /usr/local/lib/libpugixml.so.0.0 usr/local/lib/libpugixml.so.0.1
/usr/local/lib/libpugixml.so.0.0 --> usr/local/lib/libpugixml.so.0.1
Dynamic export changes:
added:
        _ZN4pugi11xpath_queryC1EOS0_
        _ZN4pugi11xpath_queryC2EOS0_
        _ZN4pugi11xpath_queryaSEOS0_
        _ZN4pugi13xml_attribute9set_valueEx
        _ZN4pugi13xml_attribute9set_valueEy
        _ZN4pugi13xml_attributeaSEx
        _ZN4pugi13xml_attributeaSEy
        _ZN4pugi14xpath_node_set5_moveERS0_
        _ZN4pugi14xpath_node_setC1EOS0_
        _ZN4pugi14xpath_node_setC2EOS0_
        _ZN4pugi14xpath_node_setaSEOS0_
        _ZN4pugi18xpath_variable_setC1EOS0_
        _ZN4pugi18xpath_variable_setC2EOS0_
        _ZN4pugi18xpath_variable_setaSEOS0_
        _ZN4pugi8xml_text3setEx
        _ZN4pugi8xml_text3setEy
        _ZN4pugi8xml_textaSEx
        _ZN4pugi8xml_textaSEy
        _ZNK4pugi13xml_attribute8as_llongEx
        _ZNK4pugi13xml_attribute9as_ullongEy
        _ZNK4pugi8xml_text8as_llongEx
        _ZNK4pugi8xml_text9as_ullongEy

External reference changes:
removed:
        _ZNSsC1ERKSs
        __isthreaded

PLT added:
        _ZN4pugi13xml_attribute9set_valueEx
        _ZN4pugi13xml_attribute9set_valueEy
        _ZN4pugi14xpath_node_set5_moveERS0_
        _ZN4pugi8xml_text3setEx
        _ZN4pugi8xml_text3setEy

-->8--

check_sym on amd64
--8<--
russell /usr/ports/pobj/pugixml-1.7/fake-amd64$ /usr/src/lib/check_sym /usr/local/lib/libpugixml.so.0.0  usr/local/lib/libpugixml.so.*
/usr/local/lib/libpugixml.so.0.0 --> usr/local/lib/libpugixml.so.0.1
No dynamic export changes
-->8--

ok?


Index: Makefile
===================================================================
RCS file: /cvs/ports/textproc/pugixml/Makefile,v
retrieving revision 1.8
diff -u -p -r1.8 Makefile
--- Makefile 24 Oct 2018 14:28:11 -0000 1.8
+++ Makefile 20 Mar 2019 14:18:16 -0000
@@ -4,9 +4,9 @@ COMMENT= light-weight, simple and fast X
 
 V= 1.7
 DISTNAME= pugixml-$V
-REVISION = 3
+REVISION = 4
 
-SHARED_LIBS += pugixml                   0.0 # 1.7
+SHARED_LIBS += pugixml                   0.1 # 1.7
 
 CATEGORIES= textproc devel
 
Index: patches/patch-scripts_CMakeLists_txt
===================================================================
RCS file: patches/patch-scripts_CMakeLists_txt
diff -N patches/patch-scripts_CMakeLists_txt
--- patches/patch-scripts_CMakeLists_txt 30 Nov 2015 14:32:27 -0000 1.1.1.1
+++ /dev/null 1 Jan 1970 00:00:00 -0000
@@ -1,23 +0,0 @@
-$OpenBSD: patch-scripts_CMakeLists_txt,v 1.1.1.1 2015/11/30 14:32:27 sthen Exp $
---- scripts/CMakeLists.txt.orig Mon Nov 30 12:58:48 2015
-+++ scripts/CMakeLists.txt Mon Nov 30 12:58:53 2015
-@@ -26,9 +26,9 @@ else()
- endif()
-
- # Enable C++11 long long for compilers that are capable of it
--if(NOT ${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION} STRLESS 3.1)
-- target_compile_features(pugixml PUBLIC cxx_long_long_type)
--endif()
-+#if(NOT ${CMAKE_MAJOR_VERSION}.${CMAKE_MINOR_VERSION} STRLESS 3.1)
-+# target_compile_features(pugixml PUBLIC cxx_long_long_type)
-+#endif()
-
- set_target_properties(pugixml PROPERTIES VERSION 1.7 SOVERSION 1)
-
-@@ -49,4 +49,4 @@ if(BUILD_TESTS)
- add_executable(check ${TEST_SOURCES})
- target_link_libraries(check pugixml)
- add_custom_command(TARGET check POST_BUILD COMMAND check WORKING_DIRECTORY ${CMAKE_SOURCE_DIR}/..)
--endif()
-\ No newline at end of file
-+endif()


--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Reply | Threaded
Open this post in threaded view
|

Re: pugixml and ports-gcc

Charlene Wendling
Hi,

On Wed, 20 Mar 2019 15:48:58 +0100
Jeremie Courreges-Anglas <[hidden email]> wrote:

>
> Hi,
>
> filezilla fails to build at least on powerpc and sparc64:
>
>   http://build-failures.rhaalovely.net/powerpc/2019-02-04/net/filezilla.log
>   http://build-failures.rhaalovely.net/sparc64/2019-03-04/net/filezilla.log
>
> --8<--
> checking whether pugixml has been compiled with long long support...
> no configure: error: pugixml system library has been compiled without
> long long support
> -->8--
>
> We have a local patch that prevents cmake from turning on long long
> (C++11) support.  I guess the diff was needed to avoid a failure with
> cmake-3.1.x and/or base-gcc, back in 2015.
>
> If I remove our local patch, cmake-3.10.2 and ports-gcc happily build
> a library with long long support activated.  base-clang builds aren't
> affected (long long support by default).

Thanks a lot!

I've tested on macppc, your diff solves the 'long long' issue at
filezilla's configure time (But the build fails later sadly, and i'm
building webkitgtk4 atm).

By the way, HOMEPAGE should be moved to https.

Charlène.

> jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE
> 1524 E7EE
>

Reply | Threaded
Open this post in threaded view
|

Re: pugixml and ports-gcc

Jeremie Courreges-Anglas-2
On Wed, Mar 20 2019, Charlene Wendling <[hidden email]> wrote:

> Hi,
>
> On Wed, 20 Mar 2019 15:48:58 +0100
> Jeremie Courreges-Anglas <[hidden email]> wrote:
>
>>
>> Hi,
>>
>> filezilla fails to build at least on powerpc and sparc64:
>>
>>   http://build-failures.rhaalovely.net/powerpc/2019-02-04/net/filezilla.log
>>   http://build-failures.rhaalovely.net/sparc64/2019-03-04/net/filezilla.log
>>
>> --8<--
>> checking whether pugixml has been compiled with long long support...
>> no configure: error: pugixml system library has been compiled without
>> long long support
>> -->8--
>>
>> We have a local patch that prevents cmake from turning on long long
>> (C++11) support.  I guess the diff was needed to avoid a failure with
>> cmake-3.1.x and/or base-gcc, back in 2015.
>>
>> If I remove our local patch, cmake-3.10.2 and ports-gcc happily build
>> a library with long long support activated.  base-clang builds aren't
>> affected (long long support by default).
>
> Thanks a lot!
>
> I've tested on macppc, your diff solves the 'long long' issue at
> filezilla's configure time (But the build fails later sadly, and i'm
> building webkitgtk4 atm).

Yeah I suspected that but figured that the diff would still be an
improvement.

> By the way, HOMEPAGE should be moved to https.

And HOMEPAGE says pugixml-1.9 has been released, so here's a diff for
both.  Not tested yet, if someone wants to pick it up:


Index: Makefile
===================================================================
RCS file: /cvs/ports/textproc/pugixml/Makefile,v
retrieving revision 1.9
diff -u -p -r1.9 Makefile
--- Makefile 21 Mar 2019 16:11:42 -0000 1.9
+++ Makefile 21 Mar 2019 16:29:58 -0000
@@ -2,15 +2,14 @@
 
 COMMENT= light-weight, simple and fast XML parser for C++
 
-V= 1.7
+V= 1.9
 DISTNAME= pugixml-$V
-REVISION = 4
 
-SHARED_LIBS += pugixml                   0.1 # 1.7
+SHARED_LIBS += pugixml                   1.0 # 1.9
 
 CATEGORIES= textproc devel
 
-HOMEPAGE= http://pugixml.org/
+HOMEPAGE= https://pugixml.org/
 
 MAINTAINER= Stuart Henderson <[hidden email]>
 
@@ -28,7 +27,5 @@ MODULES= devel/cmake
 CONFIGURE_ARGS+= -DBUILD_SHARED_LIBS=on
 
 NO_TEST= Yes
-
-WRKSRC= ${WRKDIST}/scripts
 
 .include <bsd.port.mk>
Index: distinfo
===================================================================
RCS file: /cvs/ports/textproc/pugixml/distinfo,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 distinfo
--- distinfo 30 Nov 2015 14:32:27 -0000 1.1.1.1
+++ distinfo 21 Mar 2019 16:29:58 -0000
@@ -1,2 +1,2 @@
-SHA256 (pugixml-1.7.tar.gz) = ++ENRvYddp99kqKWEC5OK9PuFhMPEcWxChquWQ6h9co=
-SIZE (pugixml-1.7.tar.gz) = 354472
+SHA256 (pugixml-1.9.tar.gz) = 0VbTW4P2gOQP1kEsRFX90DVEM5d5E0YXubKNGeEf26Y=
+SIZE (pugixml-1.9.tar.gz) = 377369


--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF  DDCC 0DFA 74AE 1524 E7EE

Reply | Threaded
Open this post in threaded view
|

Re: pugixml and ports-gcc

Stuart Henderson-6
On 2019/03/21 17:33, Jeremie Courreges-Anglas wrote:

> On Wed, Mar 20 2019, Charlene Wendling <[hidden email]> wrote:
> > Hi,
> >
> > On Wed, 20 Mar 2019 15:48:58 +0100
> > Jeremie Courreges-Anglas <[hidden email]> wrote:
> >
> >>
> >> Hi,
> >>
> >> filezilla fails to build at least on powerpc and sparc64:
> >>
> >>   http://build-failures.rhaalovely.net/powerpc/2019-02-04/net/filezilla.log
> >>   http://build-failures.rhaalovely.net/sparc64/2019-03-04/net/filezilla.log
> >>
> >> --8<--
> >> checking whether pugixml has been compiled with long long support...
> >> no configure: error: pugixml system library has been compiled without
> >> long long support
> >> -->8--
> >>
> >> We have a local patch that prevents cmake from turning on long long
> >> (C++11) support.  I guess the diff was needed to avoid a failure with
> >> cmake-3.1.x and/or base-gcc, back in 2015.
> >>
> >> If I remove our local patch, cmake-3.10.2 and ports-gcc happily build
> >> a library with long long support activated.  base-clang builds aren't
> >> affected (long long support by default).
> >
> > Thanks a lot!
> >
> > I've tested on macppc, your diff solves the 'long long' issue at
> > filezilla's configure time (But the build fails later sadly, and i'm
> > building webkitgtk4 atm).
>
> Yeah I suspected that but figured that the diff would still be an
> improvement.
>
> > By the way, HOMEPAGE should be moved to https.
>
> And HOMEPAGE says pugixml-1.9 has been released, so here's a diff for
> both.  Not tested yet, if someone wants to pick it up:

Dep's seem ok, the changelog is sane ... OK with me.
I wonder why portroach didn't find the update.