Build errors

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Build errors

Peter Kovacs-3
Hi all,


1)

I have a build error on latest trunk while building

/usr/bin/ld: cannot find -luno_salhelpergcc3

I worked around it with build --from salhelper


Maybe some dependency is missing in registry module?


2)

Have a build error in registry

'../unxlngx6.pro/slo/bitmapdevice.obj'

/home/legine/workspace/ApacheOpenOffice/git/main/basebmp/source/bitmapdevice.cxx:2060:1:
required from here
../inc/basebmp/packedpixeliterator.hxx:54:19: warning: left shift of
negative value [-Wshift-negative-value]
      return ((~(~0 << bits_per_pixel)) << bits_per_pixel*(MsbFirst ?

../inc/basebmp/packedpixeliterator.hxx:86:23: error: left operand of
shift expression '(-1 << 4)' is negative [-fpermissive]
../inc/basebmp/packedpixeliterator.hxx:80:10: error: enumerator value
for 'bit_mask' is not an integer constant
      enum {
           ^

Maybe this is about my compiler. (I use gcc 7.2.0 :P ) I will check
tonight. However if someone has an idea. Help is apreciated.


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Build errors

Peter Kovacs-3
Hi there,


so I tried all solutions from Dennis E. Hammilton From 2.1.2017:

> Try a couple of things:
>
>   1. Put spaces in the "=~" to be something like " = ~" in the definition of bit_mask.
>
>   2. If that makes no difference, try
>
>            bit_mask = ~ ((value_type)(~0 << bits_per_pixel))
>
>      and if that doesn't work, see if
>
>            bit_mask = ~ ((int)(~0 << bits_per_pixel))
>
>      or even
>
>            bit_mask = (int) (~(~0 << bits_per_pixel))
>
>      get the job done.
>
> It seems strange for an enum being used this way.  It is a clumsy way to define two numeric constants that are not involved in an enumeration at all.
>
>>       };
All failed now. The Compiler is allways complaining on on the << part, ignoring the casts.
Patricia suggested that I work with a "wrong" configuration back then. This is definitly true. My distro enables C++17 (Letest shit yadada ;) )
And I do not know how to switch it off. So it could well be that over time the Code broke.

One possibility could be to switch all modern Standards off. But maybe we should simply consider to write this part of the code again, with the goal that it works with the old and new ones.
So I think I will try this. It does not make any differences if I can compile anyhow.

Opinions?


On 07.11.2017 10:23, Peter Kovacs wrote:

> Hi all,
>
>
> 1)
>
> I have a build error on latest trunk while building
>
> /usr/bin/ld: cannot find -luno_salhelpergcc3
>
> I worked around it with build --from salhelper
>
>
> Maybe some dependency is missing in registry module?
>
>
> 2)
>
> Have a build error in registry
>
> '../unxlngx6.pro/slo/bitmapdevice.obj'
>
> /home/legine/workspace/ApacheOpenOffice/git/main/basebmp/source/bitmapdevice.cxx:2060:1:
> required from here
> ../inc/basebmp/packedpixeliterator.hxx:54:19: warning: left shift of
> negative value [-Wshift-negative-value]
>      return ((~(~0 << bits_per_pixel)) << bits_per_pixel*(MsbFirst ?
>
> ../inc/basebmp/packedpixeliterator.hxx:86:23: error: left operand of
> shift expression '(-1 << 4)' is negative [-fpermissive]
> ../inc/basebmp/packedpixeliterator.hxx:80:10: error: enumerator value
> for 'bit_mask' is not an integer constant
>      enum {
>           ^
>
> Maybe this is about my compiler. (I use gcc 7.2.0 :P ) I will check
> tonight. However if someone has an idea. Help is apreciated.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>

Reply | Threaded
Open this post in threaded view
|

Re: Build errors

Andrea Pescetti-2
Peter Kovacs wrote:
> But maybe we should simply consider to write this part of the code
> again, with the goal that it works with the old and new ones.
> So I think I will try this. It does not make any differences if I can
> compile anyhow.
> Opinions?

Did you ever get a successful build, on any system? If not, I would
suggest that you try building trunk in a VM first. Within a couple hours
you should be able to install the VM, setup the environment and complete
the build.

This way you can make sure that you are not missing any details about
the build process and you can also check that your changes (on your
main, recent, system) are compatible with older systems. The wiki has a
detailed list of tips for many Linux-based distributions, but just ask
here if you need more details.

Regards,
   Andrea.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Build errors

Don Lewis-2
In reply to this post by Peter Kovacs-3
On  7 Nov, Peter Kovacs wrote:

> Hi there,
>
>
> so I tried all solutions from Dennis E. Hammilton From 2.1.2017:
>
>> Try a couple of things:
>>
>>   1. Put spaces in the "=~" to be something like " = ~" in the definition of bit_mask.
>>
>>   2. If that makes no difference, try
>>
>>            bit_mask = ~ ((value_type)(~0 << bits_per_pixel))
>>
>>      and if that doesn't work, see if
>>
>>            bit_mask = ~ ((int)(~0 << bits_per_pixel))
>>
>>      or even
>>
>>            bit_mask = (int) (~(~0 << bits_per_pixel))
>>
>>      get the job done.
>>
>> It seems strange for an enum being used this way.  It is a clumsy way to define two numeric constants that are not involved in an enumeration at all.
>>
>>>       };
> All failed now. The Compiler is allways complaining on on the << part, ignoring the casts.
> Patricia suggested that I work with a "wrong" configuration back then. This is definitly true. My distro enables C++17 (Letest shit yadada ;) )
> And I do not know how to switch it off. So it could well be that over time the Code broke.
>
> One possibility could be to switch all modern Standards off. But maybe we should simply consider to write this part of the code again, with the goal that it works with the old and new ones.
> So I think I will try this. It does not make any differences if I can compile anyhow.
>
> Opinions?
>
>
> On 07.11.2017 10:23, Peter Kovacs wrote:
>> Hi all,
>>
>>
>> 1)
>>
>> I have a build error on latest trunk while building
>>
>> /usr/bin/ld: cannot find -luno_salhelpergcc3
>>
>> I worked around it with build --from salhelper
>>
>>
>> Maybe some dependency is missing in registry module?
>>
>>
>> 2)
>>
>> Have a build error in registry
>>
>> '../unxlngx6.pro/slo/bitmapdevice.obj'
>>
>> /home/legine/workspace/ApacheOpenOffice/git/main/basebmp/source/bitmapdevice.cxx:2060:1:
>> required from here
>> ../inc/basebmp/packedpixeliterator.hxx:54:19: warning: left shift of
>> negative value [-Wshift-negative-value]
>>      return ((~(~0 << bits_per_pixel)) << bits_per_pixel*(MsbFirst ?
>>
>> ../inc/basebmp/packedpixeliterator.hxx:86:23: error: left operand of
>> shift expression '(-1 << 4)' is negative [-fpermissive]
>> ../inc/basebmp/packedpixeliterator.hxx:80:10: error: enumerator value
>> for 'bit_mask' is not an integer constant
>>      enum {
>>           ^
>>
>> Maybe this is about my compiler. (I use gcc 7.2.0 :P ) I will check
>> tonight. However if someone has an idea. Help is apreciated.

On a two-complement machine, ~0 evaluates to -1, and in C, the result of
shifting a negative value is undefined.  Most machines will do an
arithmetic shift, but some machines (powerpc?) don't have arithmetic
shift hardware and will do a logical shift.  Try changing ~0 to ~0u so
that it is treated as an unsigned value, which is probably what is
intended here.  It shouldn't make a difference for -1, but it does make
a difference for other negative values.



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Build errors

Peter Kovacs-3
In reply to this post by Andrea Pescetti-2
My laptops have not enough disk space for a VM. My desktop I see when I return from work for sleeping.
I am currently traveling a lot.
Sorry not an option atm.

In December I will probably upgrade my disk space on one of the machine. (Not sure if I can upgrade the MacOS one. You know Apple and Standard are not compatible features. ;) ) then I will use VM for compiling.

Am 7. November 2017 22:45:25 MEZ schrieb Andrea Pescetti <[hidden email]>:

>Peter Kovacs wrote:
>> But maybe we should simply consider to write this part of the code
>> again, with the goal that it works with the old and new ones.
>> So I think I will try this. It does not make any differences if I can
>> compile anyhow.
>> Opinions?
>
>Did you ever get a successful build, on any system? If not, I would
>suggest that you try building trunk in a VM first. Within a couple
>hours
>you should be able to install the VM, setup the environment and
>complete
>the build.
>
>This way you can make sure that you are not missing any details about
>the build process and you can also check that your changes (on your
>main, recent, system) are compatible with older systems. The wiki has a
>
>detailed list of tips for many Linux-based distributions, but just ask
>here if you need more details.
>
>Regards,
>   Andrea.
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Build errors

Peter Kovacs-3
In reply to this post by Don Lewis-2
Thanks a lot! I am sorry I do not have in depth skill of c/c++ and did not know what to search for.
Will read this up!
Thank you so much!

Am 8. November 2017 04:59:52 MEZ schrieb Don Lewis <[hidden email]>:

>On  7 Nov, Peter Kovacs wrote:
>> Hi there,
>>
>>
>> so I tried all solutions from Dennis E. Hammilton From 2.1.2017:
>>
>>> Try a couple of things:
>>>
>>>   1. Put spaces in the "=~" to be something like " = ~" in the
>definition of bit_mask.
>>>
>>>   2. If that makes no difference, try
>>>
>>>            bit_mask = ~ ((value_type)(~0 << bits_per_pixel))
>>>
>>>      and if that doesn't work, see if
>>>
>>>            bit_mask = ~ ((int)(~0 << bits_per_pixel))
>>>
>>>      or even
>>>
>>>            bit_mask = (int) (~(~0 << bits_per_pixel))
>>>
>>>      get the job done.
>>>
>>> It seems strange for an enum being used this way.  It is a clumsy
>way to define two numeric constants that are not involved in an
>enumeration at all.
>>>
>>>>       };
>> All failed now. The Compiler is allways complaining on on the <<
>part, ignoring the casts.
>> Patricia suggested that I work with a "wrong" configuration back
>then. This is definitly true. My distro enables C++17 (Letest shit
>yadada ;) )
>> And I do not know how to switch it off. So it could well be that over
>time the Code broke.
>>
>> One possibility could be to switch all modern Standards off. But
>maybe we should simply consider to write this part of the code again,
>with the goal that it works with the old and new ones.
>> So I think I will try this. It does not make any differences if I can
>compile anyhow.
>>
>> Opinions?
>>
>>
>> On 07.11.2017 10:23, Peter Kovacs wrote:
>>> Hi all,
>>>
>>>
>>> 1)
>>>
>>> I have a build error on latest trunk while building
>>>
>>> /usr/bin/ld: cannot find -luno_salhelpergcc3
>>>
>>> I worked around it with build --from salhelper
>>>
>>>
>>> Maybe some dependency is missing in registry module?
>>>
>>>
>>> 2)
>>>
>>> Have a build error in registry
>>>
>>> '../unxlngx6.pro/slo/bitmapdevice.obj'
>>>
>>>
>/home/legine/workspace/ApacheOpenOffice/git/main/basebmp/source/bitmapdevice.cxx:2060:1:
>
>>> required from here
>>> ../inc/basebmp/packedpixeliterator.hxx:54:19: warning: left shift of
>
>>> negative value [-Wshift-negative-value]
>>>      return ((~(~0 << bits_per_pixel)) << bits_per_pixel*(MsbFirst ?
>>>
>>> ../inc/basebmp/packedpixeliterator.hxx:86:23: error: left operand of
>
>>> shift expression '(-1 << 4)' is negative [-fpermissive]
>>> ../inc/basebmp/packedpixeliterator.hxx:80:10: error: enumerator
>value
>>> for 'bit_mask' is not an integer constant
>>>      enum {
>>>           ^
>>>
>>> Maybe this is about my compiler. (I use gcc 7.2.0 :P ) I will check
>>> tonight. However if someone has an idea. Help is apreciated.
>
>On a two-complement machine, ~0 evaluates to -1, and in C, the result
>of
>shifting a negative value is undefined.  Most machines will do an
>arithmetic shift, but some machines (powerpc?) don't have arithmetic
>shift hardware and will do a logical shift.  Try changing ~0 to ~0u so
>that it is treated as an unsigned value, which is probably what is
>intended here.  It shouldn't make a difference for -1, but it does make
>a difference for other negative values.
>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [hidden email]
>For additional commands, e-mail: [hidden email]

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: Build errors

Peter Kovacs-3
I have reviewd my Issue. It seems to be a side effect of enum construction.

My guess is that with the new standard there is a new implementation of
enum, that triggers this logic shift as a sideeffect. Not sure but from
what I read it seems bit shifting is not commonly used in c++.

I have not reached out to the gcc folk. I think this creative use of
enumn is maybe not the best construct to use anyhow. No need to advertise.


What I did was isolation of the code in question. Starting with the
bit_mask definiton and expanded slowly, line by line. Then I slowly
extended the code.

I tried both variation with ~0u and ~0.

After I start embed the Code in the enum construct it worked only with
~0u as expected. I even found out how to switch standard. So I will
continue my OpenOffice Compiles on 98 standard.

I hope that reduces some issues and a lot of warnings I had.


So I would like to check in a least invasiv change and replace ~0 with ~0u.
However I would like to remove the enum in a second step, since the
construction with the enum looks to creative for my taste. 2 const
variables should do the same trick.
Plus I would like to, in a third step, reduce code, by introducing a
hierarchy to the classes PackedPixelColumnIterator and
PackedPixelRowIterator

So in result we would get

                                 nonstandard Iterator
                                             A
                                             |
                            PackedPixelIterator
                                   A               A
                                    |                |
PackedPixelColumnIterator  PackedPixelRowIterator

But that needs some doing.
I would put in all 3 Things in Bugzilla but only fix the 1) step now,
and leave the other 2 things when I have build the Code at least once.

Opinions?

All the best
Peter

On 08.11.2017 07:40, Peter kovacs wrote:

> Thanks a lot! I am sorry I do not have in depth skill of c/c++ and did not know what to search for.
> Will read this up!
> Thank you so much!
>
> Am 8. November 2017 04:59:52 MEZ schrieb Don Lewis <[hidden email]>:
>> On  7 Nov, Peter Kovacs wrote:
>>> Hi there,
>>>
>>>
>>> so I tried all solutions from Dennis E. Hammilton From 2.1.2017:
>>>
>>>> Try a couple of things:
>>>>
>>>>    1. Put spaces in the "=~" to be something like " = ~" in the
>> definition of bit_mask.
>>>>    2. If that makes no difference, try
>>>>
>>>>             bit_mask = ~ ((value_type)(~0 << bits_per_pixel))
>>>>
>>>>       and if that doesn't work, see if
>>>>
>>>>             bit_mask = ~ ((int)(~0 << bits_per_pixel))
>>>>
>>>>       or even
>>>>
>>>>             bit_mask = (int) (~(~0 << bits_per_pixel))
>>>>
>>>>       get the job done.
>>>>
>>>> It seems strange for an enum being used this way.  It is a clumsy
>> way to define two numeric constants that are not involved in an
>> enumeration at all.
>>>>>        };
>>> All failed now. The Compiler is allways complaining on on the <<
>> part, ignoring the casts.
>>> Patricia suggested that I work with a "wrong" configuration back
>> then. This is definitly true. My distro enables C++17 (Letest shit
>> yadada ;) )
>>> And I do not know how to switch it off. So it could well be that over
>> time the Code broke.
>>> One possibility could be to switch all modern Standards off. But
>> maybe we should simply consider to write this part of the code again,
>> with the goal that it works with the old and new ones.
>>> So I think I will try this. It does not make any differences if I can
>> compile anyhow.
>>> Opinions?
>>>
>>>
>>> On 07.11.2017 10:23, Peter Kovacs wrote:
>>>> Hi all,
>>>>
>>>>
>>>> 1)
>>>>
>>>> I have a build error on latest trunk while building
>>>>
>>>> /usr/bin/ld: cannot find -luno_salhelpergcc3
>>>>
>>>> I worked around it with build --from salhelper
>>>>
>>>>
>>>> Maybe some dependency is missing in registry module?
>>>>
>>>>
>>>> 2)
>>>>
>>>> Have a build error in registry
>>>>
>>>> '../unxlngx6.pro/slo/bitmapdevice.obj'
>>>>
>>>>
>> /home/legine/workspace/ApacheOpenOffice/git/main/basebmp/source/bitmapdevice.cxx:2060:1:
>>
>>>> required from here
>>>> ../inc/basebmp/packedpixeliterator.hxx:54:19: warning: left shift of
>>>> negative value [-Wshift-negative-value]
>>>>       return ((~(~0 << bits_per_pixel)) << bits_per_pixel*(MsbFirst ?
>>>>
>>>> ../inc/basebmp/packedpixeliterator.hxx:86:23: error: left operand of
>>>> shift expression '(-1 << 4)' is negative [-fpermissive]
>>>> ../inc/basebmp/packedpixeliterator.hxx:80:10: error: enumerator
>> value
>>>> for 'bit_mask' is not an integer constant
>>>>       enum {
>>>>            ^
>>>>
>>>> Maybe this is about my compiler. (I use gcc 7.2.0 :P ) I will check
>>>> tonight. However if someone has an idea. Help is apreciated.
>> On a two-complement machine, ~0 evaluates to -1, and in C, the result
>> of
>> shifting a negative value is undefined.  Most machines will do an
>> arithmetic shift, but some machines (powerpc?) don't have arithmetic
>> shift hardware and will do a logical shift.  Try changing ~0 to ~0u so
>> that it is treated as an unsigned value, which is probably what is
>> intended here.  It shouldn't make a difference for -1, but it does make
>> a difference for other negative values.
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [hidden email]
>> For additional commands, e-mail: [hidden email]
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]