Issue 128222

Summary: cannot complete the build on slackware64-current linux
Product: General Reporter: yury_t <yury.tarasievich>
Component: codeAssignee: AOO issues mailing list <issues>
Status: UNCONFIRMED --- QA Contact:
Severity: Normal    
Priority: P5 (lowest) CC: petko
Version: 4.2.0-dev   
Target Milestone: ---   
Hardware: PC   
OS: Linux 64-bit   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Attachments:
Description Flags
patch for the problem with files generated from writerfilter/source/ooxml none

Description yury_t 2019-11-06 20:35:49 UTC 
I was trying to build the 'trunk' (4.5.0) on 64-bit slackware-current. There were several problematic places in the code blocking the build successful completion.
I have no good understanding of the problems, but I managed to 'kludge' those. Build completes, and I'm able to launch and use the applications, at least at the first look.
The system is 4.19.75, gcc (GCC) 9.2.0, javac 1.8.0_212, xsltproc is: 
Using libxml 20909, libxslt 10133 and libexslt 820
xsltproc was compiled against libxml 20909, libxslt 10133 and libexslt 820
libxslt 10133 was compiled against libxml 20909
libexslt 820 was compiled against libxml 20909.

./configure   \
--with-build-version="$(date +"%Y-%m-%d %H:%M") - `uname -sm`" \
--enable-verbose \
--enable-crashdump=yes  \
--enable-opengl  \
--enable-dbus  \
--with-package-format="installed" \
--with-dmake-url=https://sourceforge.net/projects/oooextras.mirror/files/dmake-4.12.tar.bz2 \
--with-epm-url=https://sourceforge.net/projects/oooextras.mirror/files/epm-3.7.tar.gz \
--without-junit \
--without-stlport \
--with-system-stdlibs \
\
--disable-gstreamer \
--disable-wiki-publisher  \
--disable-bundled-dictionaries \
--disable-category-b \
--disable-pam \
\
  --with-jdk-home=/usr/lib64/java \
\
--with-system-libs=no \
  --enable-hyphen \
  --enable-hunspell \
  --disable-graphite \
\
\
  --with-system-lucene=no \
  --with-system-hsqldb=no \
  --with-system-beanshell=no \
  --with-system-saxon=no \
  --with-system-redland=no \
  --with-system-mythes=no \
  --with-system-icu=no \
\
  --with-system-jpeg=no \
  --with-system-openssl=no \
\
--with-system-libs=no \

(some of these are redundant, I know; but that's what was actually used in the configuration phase)

So the 1st 'kludge' is trivial:

--- basebmp/inc/basebmp/packedpixeliterator.hxx.prev<-->2019-11-05 09:14:46.448745490 +0300
+++ basebmp/inc/basebmp/packedpixeliterator.hxx>2019-11-05 14:32:44.622455058 +0300
@@ -608,7 +608,7 @@
.
     value_type get(difference_type const & d) const
     {
-        const int remainder( x(d.x) % num_intraword_positions );
+        const int remainder( (d.x) % num_intraword_positions );
.
         return (unsigned_cast<value_type>(*current(d.x,d.y) &.
                                           get_mask<value_type, bits_per_pixel, MsbFirst>(remainder))

The 2nd one is more complicated. I'm attaching the patch, and the essence of the problem is some of the comparisons of the values produced by 'generate-id' fail unexpectedly at the 1st use of a template using such a comparison (all subsequent template's uses work as expected).

I had to do that crap with bogus entry as it gets dropped from generated files anyway, and replacing 'generate-id(.)' with 'generate-id(current())' doesn't work here.
Comment 1 yury_t 2019-11-06 20:37:15 UTC 
Created attachment 86758 [details]
patch for the problem with files generated from writerfilter/source/ooxml
Comment 2 Peter 2019-11-06 22:11:51 UTC 
Hi, we just had a discussion about this issue on development mailing list.
The issue occurs when not compiled in gnu++98 mode.

Since the code seems that it is not used anywhere we have commented it out in trunc (4.5.0) in probably a later commit. 

I am currious we accept changes now via github. Do you prefer bugzilla or is github also an option you would use in the future?
Comment 3 yury_t 2019-11-07 04:57:20 UTC 
I've browsed the discussions you mention.

The 1st correction (x(d.x) thingy) is trivial, indeed.

However, I didn't see anything about the 2nd one (first-time comparisons in XSLT failing), while this might be indicating more serious problems present, caused by the newer C++ standard being used in building. I understand the build system uses its own 'xsltproc' instance?

As for the bug reporting, I'd prefer Bugzilla. I'm not what you'd call 'a real developer' and I don't understand well git's branching/merging stuff (if at all); also Github's issues tracking system seems rather inconvenient to me.

I could post brief stuff to the -devs mailing list, too (like some notes on dependencies order), if someone's watching.