On 12-04-2012 22:32, Frank Warmerdam wrote:
On Thu, Apr 12, 2012 at 2:31 PM, Frank Warmerdam wrote:
On Thu, Apr 12, 2012 at 2:09 PM, Joaquim Luis wrote:
While at this, could I make a small request that VERSION variable in
nmake.opt be wrapped in a IFNDEF so that we can optionally set it insid
On Thu, Apr 12, 2012 at 2:31 PM, Frank Warmerdam wrote:
> On Thu, Apr 12, 2012 at 2:09 PM, Joaquim Luis wrote:
>> While at this, could I make a small request that VERSION variable in
>> nmake.opt be wrapped in a IFNDEF so that we can optionally set it inside
>> nmake.local? It would be something
On Thu, Apr 12, 2012 at 2:09 PM, Joaquim Luis wrote:
> While at this, could I make a small request that VERSION variable in
> nmake.opt be wrapped in a IFNDEF so that we can optionally set it inside
> nmake.local? It would be something like
>
> # Version number embedded in DLL name.
> !IFNDEF VERS
On 12-04-2012 16:00, Ivan Lucena wrote:
Olá Joaquim,
Sometimes a SVN update bring things that require a complete clean up before we
can rebuild it again, so you need to run:
nmake -f makefile.vc clean
nmake -f makefile.vc
nmake -f makefile.vc install
Ivan, obrigado but ... I wish it was that
On 12-04-2012 16:24, Jeff McKenna wrote:
Hi Joaquim,
I've definitely been in a similar situation before. Most of the time,
when I get those 'LIBCMT' or 'MSVCRT' conflict messages, it is because I
built a dependent library with the /MT option by mistake, causing the
GDAL built to try to include
Hi Joaquim,
I've definitely been in a similar situation before. Most of the time,
when I get those 'LIBCMT' or 'MSVCRT' conflict messages, it is because I
built a dependent library with the /MT option by mistake, causing the
GDAL built to try to include LIBCMT.lib (but GDAL and all of its
depende
Cc: gdal
> Subject: Re: [gdal-dev] broken trunk build on Win
> Sent: Apr 12 '12 09:06
>
> On 12 April 2012 14:34, Joaquim Luis wrote:
> >
> >>>>> I made some false reports in the past about the build failures that
> >>>>> ended up
I made some false reports in the past about the build failures that
ended up being caused by no starting by a "make clean", but that is not
the case this time.
.^^
Clean and rebuild GDAL.
As I first said ...
___
gdal-dev m
On 12 April 2012 14:15, Joaquim Luis wrote:
> On 12-04-2012 13:07, Even Rouault wrote:
>> Selon Joaquim Luis:
>>
>>> Hi,
>>>
>>> I made some false reports in the past about the build failures that
>>> ended up being caused by no starting by a "make clean", but that is not
>>> the case this time.
>
On 12-04-2012 13:07, Even Rouault wrote:
Selon Joaquim Luis:
Hi,
I made some false reports in the past about the build failures that
ended up being caused by no starting by a "make clean", but that is not
the case this time.
I'm getting these errors on linking the current head.
There must be
Selon Joaquim Luis :
> Hi,
>
> I made some false reports in the past about the build failures that
> ended up being caused by no starting by a "make clean", but that is not
> the case this time.
>
> I'm getting these errors on linking the current head.
There must be something particular in your s
Hi,
I made some false reports in the past about the build failures that
ended up being caused by no starting by a "make clean", but that is not
the case this time.
I'm getting these errors on linking the current head.
Joaquim
LIBCMT.lib(dosmap.obj) : error LNK2005: _errno already defined in
12 matches
Mail list logo
