On Tue, 2014-09-02 at 20:17 +, Carlos Argáez García wrote:
> /opt/intel/composer_xe_2013_sp1.3.174/bin/intel64/ifort -O3 -c
> second_INT_ETIME.f -o second_INT_ETIME.o
> second_INT_ETIME.f(53): error #6407: This symbolic name is not an
> intrinsic function name or an intrinsic subroutine na
On Thu, 2011-09-08 at 15:54 -0500, Dennis Sonifer wrote:
> I have an HPUX 11.23 PA-RISC machine. Downloaded the make file from
> your site, make-3.82.tar.gz. I am hoping there is just a setting or
> two away from perfection but I am generally unfamiliar with installing
> packages.
Looks like the
win Waterlander
From: Erwin Waterlander
Sent: Thu 6/21/2007 9:46
To: [EMAIL PROTECTED]
Cc: bug-make@gnu.org; Erwin Waterlander
Subject: RE: Problems with gmake and pipefail. make doesn't give up.
Hi,
/bin/ksh is not a Korn shell on our system. It is AT&T sh (version 1993-12-28
our /bin/ksh. If we add
; exit $$?
at the end of the line in the makefile it works.
--
Erwin Waterlander
From: Paul Smith [mailto:[EMAIL PROTECTED]
Sent: Thu 6/21/2007 4:42
To: Erwin Waterlander
Cc: bug-make@gnu.org
Subject: RE: Problems with gmake and pipefail
On Wed, 2007-06-20 at 17:32 +0200, Erwin Waterlander wrote:
> I compiled bash 3.2 locally. When I set
> SHELL=/home/waterlan/src/bash-3.2/bash -e -o pipefail everything
> works as expected. So the problem must be in the AT&T sh.
As far as I know, ksh doesn't support pipefail. If so, it's not a
Hi,
I compiled bash 3.2 locally. When I set
SHELL=/home/waterlan/src/bash-3.2/bash -e -o pipefail
everything works as expected. So the problem must be in the AT&T sh.
--
Erwin Waterlander
From: Erwin Waterlander
Sent: Wed 6/20/2007 16:46
To: bug-make@gnu.or
On Tue, 2006-12-05 at 00:35 +0100, sofia wrote:
> I'm trying to install the packages Net-Pcap0.14 but it's impossible to
> do "make",it reports:
>
> /usr/bin/ld: /usr/local/lib/libpcap.a(pcap-linux.o): no se puede usar la
> reubicación R_X86_64_32 contra `a local symbol' cuando se hace un objeto
On 04 December 2006 23:35, sofia wrote:
> Hello,
>
> I'm trying to install the packages Net-Pcap0.14 but it's impossible to
> do "make",it reports:
>
> /usr/bin/ld: /usr/local/lib/libpcap.a(pcap-linux.o): no se puede usar la
> reubicación R_X86_64_32 contra `a local symbol' cuando se hace un obj
Exactly. For the way make is conceived now, once it starts building a
target it doesn't check for any other rule which have that save target. In
other words, once make goes to build foo.o, and then it executes a rule
which imports some other rules for foo.o, those rules are just ignored.
This I t
On Mon, 30 Jun 2003, Peter A. Kerzum wrote:
> Yeah, Fabio's way seem quite clean and pretty. I agree that eval should
> support include.
>
> > Sure. You specify that the other prerequisites also depend on exe-deps:
> >
> > foo: exe-deps foo.o bar.o baz.o
> > foo.o bar.o baz.o: exe-deps
> >
>
%% "Peter A. Kerzum" <[EMAIL PROTECTED]> writes:
pak> Yeah, Fabio's way seem quite clean and pretty. I agree that eval
pak> should support include.
$(eval ...) does support include.
What Fabio wants to do is declare new prerequisites inside of a
command script. That may not be possible in a
Yeah, Fabio's way seem quite clean and pretty. I agree that eval should
support include.
Sure. You specify that the other prerequisites also depend on exe-deps:
foo: exe-deps foo.o bar.o baz.o
foo.o bar.o baz.o: exe-deps
But as far as I understand make this will cause troubles if exe-deps
%% Fabio Alemagna <[EMAIL PROTECTED]> writes:
fa> On Fri, 27 Jun 2003, Paul D. Smith wrote:
fa> automake uses recursive makefiles, which is something I want to
fa> avoid.
>> I wasn't suggesting automake in total, I was suggesting their dependency
>> generation style only... this is basi
On Fri, 27 Jun 2003, Paul D. Smith wrote:
> fa> automake uses recursive makefiles, which is something I want to
> fa> avoid.
>
> I wasn't suggesting automake in total, I was suggesting their dependency
> generation style only... this is basically what's described on my
> website.
hum... I must
On Sat, 28 Jun 2003, Paul D. Smith wrote:
> %% Fabio Alemagna <[EMAIL PROTECTED]> writes:
>
> fa> so this might be used as fall-back solution in case the make's bug
> fa> doesn't get solved.
>
> In an earlier email from you you said you were using the CVS code and
> "it worked" (or words to tha
%% Fabio Alemagna <[EMAIL PROTECTED]> writes:
fa> so this might be used as fall-back solution in case the make's bug
fa> doesn't get solved.
In an earlier email from you you said you were using the CVS code and
"it worked" (or words to that effect, I don't have the email any
longer).
Can you
On Sat, 28 Jun 2003, Fabio Alemagna wrote:
> This is the code:
>
> define getdeplist_1
> $(eval __ALLDEPS__ += $(1)) $(foreach m,$(1),$(foreach d,$($(m)/DEPS),$(if \
> $(findstring $(d),$(__ALLDEPS__)),,$(call getdeplist_1,$(d)
> endef
This one is simpler and more correct (in that it doesn't a
On Fri, 27 Jun 2003, Fabio Alemagna wrote:
> Yes, that's what I thought too, however You'd agree that it would take
> time for make to accomplish that job, and perhaps there could be other
> issues, like dependency loops, which would be impossible to solve, or very
> very difficult. It seems only p
%% Fabio Alemagna <[EMAIL PROTECTED]> writes:
fa> On Fri, 27 Jun 2003, Paul D. Smith wrote:
>> As pointed out before, if you do the dependency generation the way
>> automake does it (as described on my web site) you won't have any
>> of these problems.
fa> automake uses recursive makef
On Fri, 27 Jun 2003, Paul D. Smith wrote:
> As pointed out before, if you do the dependency generation the way
> automake does it (as described on my web site) you won't have any of
> these problems.
automake uses recursive makefiles, which is something I want to avoid.
> fa> My solution (if on
On Fri, 27 Jun 2003, Paul D. Smith wrote:
> I suggest you first either build the latest CVS code or, if you don't
> have the infrastructure for that (building from CVS requires that you
> have autoconf, automake, etc. installed already--if you don't have a
> Linux box, where these things are packag
%% Fabio Alemagna <[EMAIL PROTECTED]> writes:
fa> This is unacceptable for VERY large projects with lots of modules
fa> and .c files belonging to those modules: say I want to build
fa> module A and B only, which don't depend on any other module; since
fa> I include ALL .d files for ALL mod
%% Fabio Alemagna <[EMAIL PROTECTED]> writes:
fa> I know that, I've thought of it myself, but it just doesn't work
fa> for autogenerated header files: say foo.o depends on foo.h, but
fa> foo.h is autogenerated; now, make won't know about foo.h until
fa> next time it's invoked, because the
There are a couple of bugs in the $(eval ...) memory handling which
might be related to this.
I suggest you first either build the latest CVS code or, if you don't
have the infrastructure for that (building from CVS requires that you
have autoconf, automake, etc. installed already--if you don't ha
On Thu, 26 Jun 2003, Ted Stern wrote:
> Ah, you have autogenerated headers!
Not necessarily, but it may happen. I'm working on a complete and generic
build system, which understands "modules types", and on the basis of thos
types it takes some actions. It uses only make and the $(eval) function t
On Thu, 26 Jun 2003, Ted Stern wrote:
> Hi Fabio,
>
> Use the "-" prefix with your include statements, it's much simpler:
>
> -include $(DEPS)
>
> This will ignore the errors caused by a file not being found.
>
> More generally, you can make your dependency generation a lot simpler. See
> Paul
On 26 Jun 2003, Fabio Alemagna wrote:
> My goal is to have make include .d files only when they are actually
> needed, so that when make starts, it doesn't have to check whether any .c
> files (from which all the .d ones are generated) have changed, so I've
> come up with this solution:
Hi Fabio,
On Wed, Jun 11, 2003 at 10:36:11AM -0400, Paul D. Smith wrote:
>
> This would work:
>
> install:
> cd LINUX/mod; mod2=`echo *`
Or without launching a shell:
install:mod2 := $(patsubst LINUX/%,%,$(wildcard LINUX/*))
$(wildcard LINUX/*) will list all files in the LINUX directory
%% Regarding problems with directory in make; you wrote:
jj> I'm having problems with my makefile. I want to descend into a
jj> directory and issue shell commands to extract a list of files
jj> using either `ls` or `echo` and store in a variable.
jj> Here is the command:
%% [EMAIL PROTECTED] writes:
ch> I have some problems to make a very big project of C++ files with
ch> a structure of recursive make files. I got this problem after
ch> changing my old Pentium 233 MHz to a Athlon 1200 MHz, which makes
ch> a very big difference in speed. Both systems runn
30 matches
Mail list logo
