[Owasp-esapi-c++] Makefile Patch

[Kevin W. Wall]

Posting to this list to avoid surprises and to have record.
Hopefully nothing here too inflamatory to piss off anyone. If so,
my bad; not intentional.

Jeff: Hope you are OK w/ me posting your reply. I took out all
the nasty remarks that you make about everyone's mom. JK.
(I really left them in! ;-)

Daniel: if you could take a look at Jeff's proposed Makefile patch
just to be sure it doesn't break anything on your system. I know you
had some pains to get it to work on Windows. If they look OK,
send Jeff the not to commit his patches.

Thanks guys.
-kevin

On Tue, Aug 2, 2011 at 9:12 PM, Jeffrey Walton <noloader at gmail.com> wrote:
> On Tue, Aug 2, 2011 at 9:01 PM, Kevin W. Wall <kevin.w.wall at gmail.com> wrote:
>> Hmm...OK w/ me, but you might want to check w/ Daniel, since he was
>> griping about getting
>> this to work on Windows.  Wouldn't want to break something for him and
>> piss him off unintentionally.
>> (When I piss people off, I want them to know I intended it. ;-)
> No problem. Waiting for approval.
>
>> Also, is he using the right crypto lib? Is it really called
>> 'libcryptopp'? I thought it was 'libcrypto++'
>> or is this one of those YMMV depending on your OS???
> That depends. On Debian and Ubuntu, it is libcrypto++. On Fedora, its
> libcryptopp. Its not a problem though - we can EGREP the system and
> add the appropriate library to LDFLAGS.
>
>> I had forgotten how ugly makefiles can be. No wonder everyone uses makedep.
> Not everyone ;)
>
>> And, btw, could you change
>>
>>    OUT = libesapi++.a
>>
>> to
>>    OUT = libesapi++.so
>>
>> and make other required link edit changes to make that happen? No one
>> uses statically
>> compiled libraries any more (well, execpt perhaps some of the embedded folks or
>> high assurance folks, and IMHO, if you want high assurance, you
>> shouldn't be using
>> C++ to begin with ;-).  Or perhaps we can produce both.
> Good suggestion. Daniel and I can take a crack at it on the next pass.
> The patch only focused on warnings, flags, build (debug vs release),
> and compilers.
>
>> Lastly, I caught this on (originally) line 21 in revision r26:
>> INCLUDES =      -I. -I./esapi -I/usr/local/include
>> -I/usr/include/c++/4.4 -I/boost_1_47_0 -I/Dev-Cpp/include
>>
>>                                ^^^^            ^^^^^^^^
>>
>> I don't like this. I'd prefer something like
>> GCC_VERS = 4.4
>> BOOST_VERS = 1_47_0
>>
>> and to use
>> INCLUDES =      -I. -I./esapi -I/usr/local/include
>> -I/usr/include/c++/$(GCC_VERS) -I/boost_$(BOOST_VERS)
>> -I/Dev-Cpp/include
>>
>> so we don't have hunt all over the place for versions. Maybe the
>> GCC_VERS and BOOST_VERS
>> are automagically set.
> Agreed, but I don't even want that (personally). Use Yum or Apt-get to
> install what's needed and offered through the distribution. There's no
> need to torture users with bleeding edge stuff which has more bleeding
> edge dependencies.
>
>  # Debian and friends
>  # sudo apt-get install libcrypto++8 libcrypto++8-dbg libcrypto++-dev
>
>  # Fedora and friends
>  > su -
>  # yum install cryptopp cryptopp-devel
>
> BTW, that was the reason for `dev-prereq` - a simple makefile and test
> program to test an installation ;)
>
>> But if you can make those changes in addition to your proposed patches I'm good.
> OK, thanks.
>
>> On Tue, Aug 2, 2011 at 8:44 PM, Jeffrey Walton <noloader at gmail.com> wrote:
>>> Tuned Makefile
>>> Increased warnings to `-Wall -Wextra`
>>> Suppressed unused parameter and variable warning via -Wno-unused
>>> Suppressed `T t; t<0` for unsigned tempate types via -Wno-type-limits
>>> Added support for ICC and Comeau
>>> Added -std=c++0x as available
>>>
>>> OK to checkin?
>>>
>>> Jeff
>>>
>>> [SNIP]
>



-- 
Blog: http://off-the-wall-security.blogspot.com/
"The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We *cause* accidents."        -- Nathaniel Borenstein