Mailing List Archive: Perl: porters

dmake syntax, Win64 and MS compilers.

Index | Next | Previous | View Threaded

sisyphus1 at optusnet

Nov 7, 2009, 6:07 AM

Post #1 of 3 (62 views)
Permalink

dmake syntax, Win64 and MS compilers.

Hi,

In the win32/makefile.mk, pertaining to the building of perl with 64-bit
Microsoft compilers (in particular "Microsoft Platform SDK for Windows
Server 2003 R2"), we have:

.IF "$(WIN64)" == "define"
LIBBASEFILES = $(LIBBASEFILES) bufferoverflowU.lib
.ENDIF

With nmake there's no problem with that but, to dmake, that middle line is
an error because of the circularity regarding LIBBASEFILES. (Sorry, I've
lost the exact error message, though I can easily re-create it if that's
important.)

Is there a simple way of rewriting that middle line that both keeps dmake
happy && has the desired effect ?

I'm currently working around the problem by replacing (in makefile.mk):

#####################################
LIBBASEFILES = $(CRYPT_LIB) \
oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib \
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib \
netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib \
version.lib odbc32.lib odbccp32.lib

# The 64 bit Platform SDK compilers contain a runtime library that doesn't
# include the buffer overrun verification code used by the /GS switch.
# Since the code links against libraries that are compiled with /GS, this
# "security cookie verification" must be included via bufferoverlow.lib.
.IF "$(WIN64)" == "define"
LIBBASEFILES = $(LIBBASEFILES) bufferoverflowU.lib
.ENDIF
#####################################
with:
#####################################
# The 64 bit Platform SDK compilers contain a runtime library that doesn't
# include the buffer overrun verification code used by the /GS switch.
# Since the code links against libraries that are compiled with /GS, this
# "security cookie verification" must be included via bufferoverlow.lib.
.IF "$(WIN64)" == "define"
LIBBASEFILES = $(CRYPT_LIB) \
oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib \
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib \
netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib \
version.lib odbc32.lib odbccp32.lib bufferoverflowU.lib
.ELSE
LIBBASEFILES = $(CRYPT_LIB) \
oldnames.lib kernel32.lib user32.lib gdi32.lib winspool.lib \
comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib \
netapi32.lib uuid.lib ws2_32.lib mpr.lib winmm.lib \
version.lib odbc32.lib odbccp32.lib
.ENDIF
#####################################

But my solution is a bit long-winded if there's a simpler way of getting the
required result.

(I'd provide the 'diff -u', except that it would be clouded by all of the
other changes I've made to the makefile.mk that I'm working with.)

Two other things come to mind:

1) Why do we try to retain support for MS compilers in the makefile.mk ?
Since those compilers ship with nmake, wouldn't it make sense to decree that
the makefile.mk is for dmake only ? ... and decree that the MS compilers use
nmake and the win32/Makefile exclusively ? (Maybe not ... I've heard a
rumour that perl supports TIMTOWTDI :-)

2) Should the win32 makefile(s) be rewritten to cater for the possibility
that the MS compiler being used to build perl does *not* necessarily require
a link to bufferoverflowU.lib ? (For some 64-bit MS compilers attempting to
link to bufferoverflowU.lib is a fatal error, as that library does not exist
for them.)

Cheers,
Rob

steve.m.hay at googlemail

Nov 7, 2009, 6:57 AM

Post #2 of 3 (57 views)
Permalink

Re: dmake syntax, Win64 and MS compilers. [In reply to]

2009/11/7 Sisyphus <sisyphus1[at]optusnet.com.au>:
> Hi,
>
> In the win32/makefile.mk, pertaining to the building of perl with 64-bit
> Microsoft compilers (in particular "Microsoft Platform SDK for Windows
> Server 2003 R2"), we have:
>
> .IF "$(WIN64)" == "define"
> LIBBASEFILES = $(LIBBASEFILES) bufferoverflowU.lib
> .ENDIF
>
> With nmake there's no problem with that but, to dmake, that middle line is
> an error because of the circularity regarding LIBBASEFILES. (Sorry, I've
> lost the exact error message, though I can easily re-create it if that's
> important.)
>
> Is there a simple way of rewriting that middle line that both keeps dmake
> happy && has the desired effect ?

Yes, use +=, as is used elsewhere already.

I'd commit it now, but by ssh doesn't seem to be working...

> Two other things come to mind:
>
> 1) Why do we try to retain support for MS compilers in the makefile.mk ?
> Since those compilers ship with nmake, wouldn't it make sense to decree that
> the makefile.mk is for dmake only ? ... and decree that the MS compilers use
> nmake and the win32/Makefile exclusively ? (Maybe not ... I've heard a
> rumour that perl supports TIMTOWTDI :-)

No particular reason that I'm aware of, unless it's that some of the
free MS compilers perhaps didn't come with an nmake? Not sure, but it
doesn't normally cause much maintenance overhead.

>
> 2) Should the win32 makefile(s) be rewritten to cater for the possibility
> that the MS compiler being used to build perl does *not* necessarily require
> a link to bufferoverflowU.lib ? (For some 64-bit MS compilers attempting to
> link to bufferoverflowU.lib is a fatal error, as that library does not exist
> for them.)

Sounds like they should, yes.

steve.m.hay at googlemail

Nov 7, 2009, 7:09 AM

Post #3 of 3 (57 views)
Permalink

Re: dmake syntax, Win64 and MS compilers. [In reply to]

2009/11/7 Steve Hay <steve.m.hay[at]googlemail.com>:
> 2009/11/7 Sisyphus <sisyphus1[at]optusnet.com.au>:
>> Hi,
>>
>> In the win32/makefile.mk, pertaining to the building of perl with 64-bit
>> Microsoft compilers (in particular "Microsoft Platform SDK for Windows
>> Server 2003 R2"), we have:
>>
>> .IF "$(WIN64)" == "define"
>> LIBBASEFILES = $(LIBBASEFILES) bufferoverflowU.lib
>> .ENDIF
>>
>> With nmake there's no problem with that but, to dmake, that middle line is
>> an error because of the circularity regarding LIBBASEFILES. (Sorry, I've
>> lost the exact error message, though I can easily re-create it if that's
>> important.)
>>
>> Is there a simple way of rewriting that middle line that both keeps dmake
>> happy && has the desired effect ?
>
> Yes, use +=, as is used elsewhere already.
>
> I'd commit it now, but by ssh doesn't seem to be working...
>

It works again now after I set a push.default (not sure if that really
made the difference since it's been warning about not having one for a
while now...), so it's in as d541574574df104c39aaaba6d251728919eacd38.

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact lists@gossamer-threads.com