Re: hudsons hidden build errors

On 01/12/10 05:10, Alex Rousskov wrote:
> On 11/30/2010 03:30 AM, Tsantilas Christos wrote:
>> On 11/29/2010 04:08 AM, Amos Jeffries wrote:
>>> On Sun, 28 Nov 2010 09:51:46 -0700, Alex Rousskov
>>> <rousskov_at_measurement-factory.com> wrote:
>>>> On 11/27/2010 12:00 AM, Amos Jeffries wrote:
>>>>> There are some build problems which are not being highlighted by the
>>>>> hudson testing. Picking on FreeBSD-6.4 build because of problem #2.
>>>> ...
>>>>> libtool: compile: g++ -DHAVE_CONFIG_H -I../../.. -I../../../include
>>>>> -I../../../lib -I../../../src -I../../include -I/usr/local/include
>>>>> -I/usr/include -I/usr/include -I/usr/local/include -I/usr/include
>>>>> -I/usr/include -Wall -Wpointer-arith -Wwrite-strings -Wcomments
>>>>> -Werror
>>>>> -pipe -D_REENTRANT -D_FILE_OFFSET_BITS=64 -g -O2 -MT gadgets.lo -MD
>>>>> -MP
>>>>> -MF .deps/gadgets.Tpo -c ../../../src/ssl/gadgets.cc -fPIC -DPIC -o
>>>>> .libs/gadgets.o
>>>>> ../../../src/ssl/gadgets.cc: In function `bool
>>>>> addCnToRequest(Ssl::X509_REQ_Pointer&, const char*)':
>>>>> ../../../src/ssl/gadgets.cc:17: warning: deprecated conversion from
>>>>> string constant to `char*'
>>
>> The problem here probably is a wrong declaration of the
>> X509_NAME_add_entry_by_txt function in FreeBsd 6.4
>>
>> The code here is:
>> if (!X509_NAME_add_entry_by_txt(name.get(), "CN", MBSTRING_ASC,
>> (unsigned char *)cn, -1, -1, 0))
>> return false;
>>
>> Is it acceptable to use something like the following to bypass the error?
>> char cn_name[3];
>> strcpy(cn_name,"CN");
>> if (!X509_NAME_add_entry_by_txt(name.get(), cn_name, MBSTRING_ASC,
>> (unsigned char *)cn, -1, -1, 0))
>> return false;
>
> I would just const_cast<char*>("CN") to avoid the overhead of copying.
>
> If you do not like const_cast, you can do something like this instead:
> static char cn_name[3] = "CN";
>
>
>> I am able to compile without any problem to FreeBSD7. The FreeBSD 6.x
>> looks that it is unsupported by the FreeBSD group, it was impossible for
>> me to find FreeBSD6.4 CDs.
>> Does it make sense for us to provide squid support for an unsupported OS?
>
> Do we have any statistics on how many Squid users run on a certain
> FreeBSD version?

We support said OS because that is our packaging machine.

It does not strictly need a running executable out of the tests, but the
distribution bundle, missing file checks (done during build), and
install/uninstall cleanliness tests are required on that system.

Amos

-- 
Please be using
   Current Stable Squid 2.7.STABLE9 or 3.1.9
   Beta testers wanted for 3.2.0.3