Experimental Physics and Industrial Control System
|
Hi Dale,
this is an error I found and reported two months ago (see attached mails
for analysis, workaround and Janet's reply).
I don't know the current status, but I created Mantis Bug Report 244 now
to make sure the bug is visible and searchable. (I really should have
created the Mantis entry back then.)
Sorry for the inconveniences,
Ralph
Dale L. Brewe wrote:
I'm having a bit of a problem building epics base 3.14.8.2 w/ the
win32-x86 platform. The build progresses ok for awhile til I get
output from gnumake (3.78.1 or 3.80) that ends w/
[...]
--- Begin Message ---
Hi Janet,
I found the change that broke the non-cygwin build:
In RULES_BUILD 1.88.2.14 the line to install binaries was changed from
@$(INSTALL_PRODUCT) -d -m 555 $< $(INSTALL_BIN)
to
ifdef WIN32
@$(INSTALL_PRODUCT) -d -m 555 $<* $(INSTALL_BIN)
else
@$(INSTALL_PRODUCT) -d -m 555 $< $(INSTALL_BIN)
endif
Immediately afterwards the wildcard was taken back for BORLAND compilations.
The problem is that the standard Windows shell - or whatever make uses
to call programs on non-cygnus systems - does not allow wildcards in
this place. Changing the "$<*" to "$(wildcard $<*)" lets make do the
wildcard job, which should be the better option, anyway.
What exactly were you trying to "catch" with that wildcard? For my
Microsoft non-cygnus system I actually can't think of any other files
that would be matched by it.
I didn't commit any changes to CVS as I wasn't sure about the usefulness
of that wildcard.
So - if we need the wildcard, please change it as shown above, which
will work everywhere. If we don't need the wildcard, going back to the
traditional line is fine with me.
Cheers,
Ralph
--- End Message ---
--- Begin Message ---
The command line wildcard was introduced 2 days before R3.14.8 was released
as a quick fix for EPICS base bug # 231. See the bug notes for details.
The new Microsoft Visual c++ 2005 linker creates a .manifest file with each
executable and library (e.g. ca.dll ca.dll.manifest). It seems that this file
needs to be installed in the same directory as the executable/dll. This was a
temporary change I committed until we better understand how manifest files are
used and whether or not we need new CONFIG files for the new compiler. Ken Evans
is now looking into manifests to better understand them and to solve problems
we have with manifests for java jni libraries. Using a wildcard function seems
like a better way to implement the quick fix.
Janet
Ralph Lange wrote:
Hi -
I was thinking and talking about this issue a bit more:
Now I would say it's generally bad to use wildcards for what is done
within make target chains, as this introduces hidden dependencies that
make never has a chance to know about and resolve correctly.
Janet (or Jeff): What was this wildcard introduced for? As it's not for
the Borland (by ifdef) and not for the Microsoft (by my experience), it
can only affect the MinGW or Cygnus compilers. Are there other files
generated apart from the target dll or exe? Or does the compiler name
the target dll or exe different from the usual make target name?
Wouldn't it be possible and more appropriate to add targets or change
the target name in that case?
Cheers,
Ralph
Jeff Hill wrote:
Thanks Rlaph.
Actually surprised that I havent seen this here.
Jeff
-----Original Message-----
From: Ralph Lange [mailto:[email protected]] Sent: Monday, January
23, 2006 7:47 AM
To: Janet Anderson
Cc: EPICS Core Talk
Subject: Re: 3.14.8 / cygwin dependency
Hi Janet,
I found the change that broke the non-cygwin build:
In RULES_BUILD 1.88.2.14 the line to install binaries was changed from
@$(INSTALL_PRODUCT) -d -m 555 $< $(INSTALL_BIN)
to
ifdef WIN32
@$(INSTALL_PRODUCT) -d -m 555 $<* $(INSTALL_BIN)
else
@$(INSTALL_PRODUCT) -d -m 555 $< $(INSTALL_BIN)
endif
Immediately afterwards the wildcard was taken back for BORLAND
compilations. The problem is that the standard Windows shell - or
whatever make uses to call programs on non-cygnus systems - does not
allow wildcards in this place. Changing the "$<*" to "$(wildcard
$<*)" lets make do the wildcard job, which should be the better
option, anyway.
What exactly were you trying to "catch" with that wildcard? For my
Microsoft non-cygnus system I actually can't think of any other files
that would be matched by it.
I didn't commit any changes to CVS as I wasn't sure about the
usefulness of that wildcard.
So - if we need the wildcard, please change it as shown above, which
will work everywhere. If we don't need the wildcard, going back to
the traditional line is fine with me.
Cheers,
Ralph
--- End Message ---
- Replies:
- Re: problem building 3.14.8.2 with win32-x86 Janet Anderson
- References:
- problem building 3.14.8.2 with win32-x86 Dale L. Brewe
- Navigate by Date:
- Prev:
Pure virtual mode called kimkh
- Next:
Re: Pure virtual mode called Michael Abbott
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
problem building 3.14.8.2 with win32-x86 Dale L. Brewe
- Next:
Re: problem building 3.14.8.2 with win32-x86 Janet Anderson
- Index:
1994
1995
1996
1997
1998
1999
2000
2001
2002
2003
2004
2005
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
ANJ, 02 Sep 2010 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|