From damon.southworth at uk.bosch.com Mon Aug 7 06:52:47 2023 From: damon.southworth at uk.bosch.com (Southworth Damon (AA/EOP1-PE)) Date: Mon Aug 7 06:43:59 2023 Subject: [xsd-users] Building XSD Message-ID: Hi, We have been using xsd cxx-tree in our projects for many years now and have been fine with the (non-official?) release 4.1.0-a11 that you (Boris) provided for us to download at the time. We have this release tarball for the Window, MacOS and Linux x86_64 platforms. It has come to a point where I would also like to be able to build natively on our ARM platforms rather than cross compile. For this I wanted to get a version of xsd for this platform, so I decided to build the latest version from the xsd repository. This is done using build2 as per the instructions. I have managed to build it, but the result I achieve does not match the contents of the original tarballs that I have for the other platforms. The originals contained the following: "bin doc examples FLOSSE GPLv2 libxsd LICENSE NEWS README version" With a self contained xsd in the bin folder and the header files in libxsd. After the build2 install has completed I end up with the following: "bin include lib share" This version of xsd is dependent on the libraries built in the lib folder and there is are no headers files. Is there a way to automatically get a build that is equivalent to the downloaded tarballs? Regards, Damon Southworth From boris at codesynthesis.com Mon Aug 7 08:44:33 2023 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Aug 7 08:35:06 2023 Subject: [xsd-users] Building XSD In-Reply-To: References: Message-ID: Southworth Damon (AA/EOP1-PE) writes: > It has come to a point where I would also like to be able to build > natively on our ARM platforms rather than cross compile. For this I > wanted to get a version of xsd for this platform, so I decided to build > the latest version from the xsd repository. This is done using build2 > as per the instructions. Are you talking about these instructions or something else? https://codesynthesis.com/products/xsd/doc/install-build2.xhtml > I have managed to build it, but the result I achieve does not match > the contents of the original tarballs that I have for the other > platforms. > > The originals contained the following: > "bin doc examples FLOSSE GPLv2 libxsd LICENSE NEWS README > version" > With a self contained xsd in the bin folder and the header files in libxsd. > > After the build2 install has completed I end up with the following: > "bin include lib share" > > This version of xsd is dependent on the libraries built in the lib > folder and there is are no headers files. > > Is there a way to automatically get a build that is equivalent to the > downloaded tarballs? As a bit of background, the original layout was created half-manually, which was a lot of effort to maintain and the switch to build2 was partly motivated by that. With the build2-based build you by default get the standard Linux filesystem layout (executables in bin/, headers in include/, and libraries in lib/). While you can customize this quite a bit[1], I don't think it will be easy to achieve the old layout without some manual post-processing steps. So I would suggest that you try to go with the new layout. If there are some specific issues that you run into, let me know and we can see how they can be addressed. [1] https://build2.org/build2/doc/build2-build-system-manual.xhtml#intro-operations-install From damon.southworth at uk.bosch.com Tue Aug 8 06:35:34 2023 From: damon.southworth at uk.bosch.com (Southworth Damon (AA/EOP1-PE)) Date: Tue Aug 8 06:26:47 2023 Subject: [xsd-users] Building XSD In-Reply-To: References: Message-ID: Thanks Boris for the quick response. > Are you talking about these instructions or something else? I was referring primarily to the build instructions within the READ.md of the xsd repository. The output I referred to was after the "b install: ../xsd-install/xsd/" stage. > So I would suggest that you try to go with the new layout. If there are > some specific issues that you run into, let me know and we can see how > they can be addressed. Thanks for the information. I will look to adopt the new format. I think the only question I would have in addition to adopting this format would be: Why is the required cxx header tree not included within the include folder of the install location? These need to be included as they are used by the code generated by the xsd compiler. Regards, Damon Southworth. ________________________________ From: Boris Kolpackov Sent: Monday, August 7, 2023 1:44 PM To: Southworth Damon (AA/EOP1-PE) Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] Building XSD Southworth Damon (AA/EOP1-PE) writes: > It has come to a point where I would also like to be able to build > natively on our ARM platforms rather than cross compile. For this I > wanted to get a version of xsd for this platform, so I decided to build > the latest version from the xsd repository. This is done using build2 > as per the instructions. Are you talking about these instructions or something else? https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcodesynthesis.com%2Fproducts%2Fxsd%2Fdoc%2Finstall-build2.xhtml&data=05%7C01%7Cdamon.southworth%40uk.bosch.com%7C19760d11324b43ba6d7c08db9743fea3%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C638270090504651462%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=GDnP6eNNb8dEmj3yopBS7gry%2FOstIb3KN%2BydgUkeVhY%3D&reserved=0 > I have managed to build it, but the result I achieve does not match > the contents of the original tarballs that I have for the other > platforms. > > The originals contained the following: > "bin doc examples FLOSSE GPLv2 libxsd LICENSE NEWS README > version" > With a self contained xsd in the bin folder and the header files in libxsd. > > After the build2 install has completed I end up with the following: > "bin include lib share" > > This version of xsd is dependent on the libraries built in the lib > folder and there is are no headers files. > > Is there a way to automatically get a build that is equivalent to the > downloaded tarballs? As a bit of background, the original layout was created half-manually, which was a lot of effort to maintain and the switch to build2 was partly motivated by that. With the build2-based build you by default get the standard Linux filesystem layout (executables in bin/, headers in include/, and libraries in lib/). While you can customize this quite a bit[1], I don't think it will be easy to achieve the old layout without some manual post-processing steps. So I would suggest that you try to go with the new layout. If there are some specific issues that you run into, let me know and we can see how they can be addressed. [1] https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbuild2.org%2Fbuild2%2Fdoc%2Fbuild2-build-system-manual.xhtml%23intro-operations-install&data=05%7C01%7Cdamon.southworth%40uk.bosch.com%7C19760d11324b43ba6d7c08db9743fea3%7C0ae51e1907c84e4bbb6d648ee58410f4%7C0%7C0%7C638270090504651462%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zgG5J0tOifN%2FrUHhfxQm6%2BcE7dgBWae3rkark8p7lmc%3D&reserved=0 From boris at codesynthesis.com Tue Aug 8 09:57:32 2023 From: boris at codesynthesis.com (Boris Kolpackov) Date: Tue Aug 8 09:48:00 2023 Subject: [xsd-users] Building XSD In-Reply-To: References: Message-ID: Southworth Damon (AA/EOP1-PE) writes: > The output I referred to was after the "b install: ../xsd-install/xsd/" > stage. > > Why is the required cxx header tree not included within the include > folder of the install location? They are, you just haven't installed them. The instructions that you were following are for the development setup of XSD and the `b install: ../xsd-install/xsd/` command you refer to is part of the "To test installation of the XSD compiler..." steps. If you want to continue with what you already have (rather than using the instructions I linked to, which are more appropriate for consumption of XSD as opposed to development; I've added a note on this to README.md), then you will need to initialize libxsd in the install configuration and then install it in addition to the compiler. Something along these lines: bdep init @install -d libxsd b install: ../xsd-install/xsd/ ../xsd-install/libxsd/ From dakua.pradeep at outlook.com Mon Aug 21 06:14:51 2023 From: dakua.pradeep at outlook.com (PRADEEP DAKUA) Date: Mon Aug 21 06:05:59 2023 Subject: [xsd-users] XSD C++17 Support Message-ID: Hi , Looking forward to package for XSD supported for C++17 functions like auto_ptr are deprecated after c++14 Request if i can get the xsd zip package for Microsoft VS 2019 compatible, Appreciate your help. Windows x86 x86-64 Best Regards, Pradeep Dakua From boris at codesynthesis.com Mon Aug 21 09:29:33 2023 From: boris at codesynthesis.com (Boris Kolpackov) Date: Mon Aug 21 09:20:34 2023 Subject: [xsd-users] XSD C++17 Support In-Reply-To: References: Message-ID: PRADEEP DAKUA writes: > Looking forward to package for XSD supported for C++17 > > functions like auto_ptr are deprecated after c++14 You should be able to get rid of auto_ptr with XSD 4.0.0 if you compile your schemas with the `--std c++11` option. From damon.southworth at uk.bosch.com Tue Aug 29 12:28:00 2023 From: damon.southworth at uk.bosch.com (Southworth Damon (AA/EOP1-PE)) Date: Tue Aug 29 12:19:09 2023 Subject: [xsd-users] Building XSD In-Reply-To: References: Message-ID: Thanks Boris, So getting back to some xsd build issues I am still experiencing... On a GNU/Linux system with build2 installed, if I try to build xsd using the non-development build steps as you suggested earlier, it now ends with the following... ??????... c++ libxsd-frontend-2.1.0-b.2/libxsd-frontend/semantic-graph/cxx{union} -> libxsd-frontend-2.1.0-b.2/libxsd-frontend/semantic-graph/objs{union} c++ libxsd-frontend-2.1.0-b.2/libxsd-frontend/semantic-graph/cxx{compositors} -> libxsd-frontend-2.1.0-b.2/libxsd-frontend/semantic-graph/objs{compositors} ld libicuuc-65.1.0+8/libicu/libs{icudata} ld libicuuc-65.1.0+8/libicu/libs{icuuc} ld libicui18n-65.1.0+8/libicui18n/libs{icui18n} ld libxerces-c-3.2.4/xercesc/libs{xerces-c} ld libxsd-frontend-2.1.0-b.2/libxsd-frontend/libs{xsd-frontend} ld xsd-4.2.0-b.4/xsd/exe{xsd} info: failed to update dir{xsd-4.2.0-b.4/} I am also trying to build a version or xsd using MUSL Libc to use in our Alpine Linux docker build images. I am failing to build and install build2 into this environment. It initially fails to correctly detect the existence of strlcpy and strlcat, but if I allow this pass (unsetting the relevant HAVE_XXX), I still end up with a failure. ... + build2/b-boot --version build2 0.16.0 libbutl 0.16.0 host x86_64-alpine-linux-musl Copyright (c) 2014-2023 the build2 authors. This is free software released under the MIT license. + cd .. + build2/build2/b-boot configure config.config.hermetic=true config.cxx=g++ config.cc.coptions=-O3 config.cc.loptions=[null] config.bin.lib=shared config.bin.rpath=/usr/local/lib/build2 config.install.root=/usr/local config.install.sudo=sudo config.install.private=build2 Segmentation fault (core dumped) Do you have any suggestions I could try WRT to these? Regards, Damon Southworth ________________________________ From: Boris Kolpackov Sent: Tuesday, August 8, 2023 2:57 PM To: Southworth Damon (AA/EOP1-PE) Cc: xsd-users@codesynthesis.com Subject: Re: [xsd-users] Building XSD Southworth Damon (AA/EOP1-PE) writes: > The output I referred to was after the "b install: ../xsd-install/xsd/" > stage. > > Why is the required cxx header tree not included within the include > folder of the install location? They are, you just haven't installed them. The instructions that you were following are for the development setup of XSD and the `b install: ../xsd-install/xsd/` command you refer to is part of the "To test installation of the XSD compiler..." steps. If you want to continue with what you already have (rather than using the instructions I linked to, which are more appropriate for consumption of XSD as opposed to development; I've added a note on this to README.md), then you will need to initialize libxsd in the install configuration and then install it in addition to the compiler. Something along these lines: bdep init @install -d libxsd b install: ../xsd-install/xsd/ ../xsd-install/libxsd/ From boris at codesynthesis.com Wed Aug 30 00:42:39 2023 From: boris at codesynthesis.com (Boris Kolpackov) Date: Wed Aug 30 00:33:40 2023 Subject: [xsd-users] Building XSD In-Reply-To: References: Message-ID: Southworth Damon (AA/EOP1-PE) writes: > ??????... > c++ libxsd-frontend-2.1.0-b.2/libxsd-frontend/semantic-graph/cxx{union} -> libxsd-frontend-2.1.0-b.2/libxsd-frontend/semantic-graph/objs{union} > c++ libxsd-frontend-2.1.0-b.2/libxsd-frontend/semantic-graph/cxx{compositors} -> libxsd-frontend-2.1.0-b.2/libxsd-frontend/semantic-graph/objs{compositors} > ld libicuuc-65.1.0+8/libicu/libs{icudata} > ld libicuuc-65.1.0+8/libicu/libs{icuuc} > ld libicui18n-65.1.0+8/libicui18n/libs{icui18n} > ld libxerces-c-3.2.4/xercesc/libs{xerces-c} > ld libxsd-frontend-2.1.0-b.2/libxsd-frontend/libs{xsd-frontend} > ld xsd-4.2.0-b.4/xsd/exe{xsd} > info: failed to update dir{xsd-4.2.0-b.4/} There must be an error diagnostic earlier (where you have "..."). > I am also trying to build a version or xsd using MUSL Libc to use in our > Alpine Linux docker build images. I am failing to build and install build2 > into this environment. It initially fails to correctly detect the existence > of strlcpy and strlcat, I think I know where that is and have a fix: https://github.com/build2/libpkg-config/commit/81bc60b3 > but if I allow this pass (unsetting the relevant HAVE_XXX), I still end > up with a failure. > > ... > + build2/b-boot --version > build2 0.16.0 > libbutl 0.16.0 > host x86_64-alpine-linux-musl > Copyright (c) 2014-2023 the build2 authors. > This is free software released under the MIT license. > + cd .. > + build2/build2/b-boot configure config.config.hermetic=true config.cxx=g++ config.cc.coptions=-O3 config.cc.loptions=[null] config.bin.lib=shared config.bin.rpath=/usr/local/lib/build2 config.install.root=/usr/local config.install.sudo=sudo config.install.private=build2 > Segmentation fault (core dumped) Hm, I don't believe we've seen this before. Could you run gdb on that core and get the stack trace?