ail Code: C7004
> 1460 National Road
> Columbus, Indiana 47201
> United States
>
> -Original Message-
> From: Bahman Movaqar
> Sent: Tuesday, September 26, 2023 12:11 PM
> To: Ed L Wolf ; bug-make@gnu.org
> Subject: Re: Problem setting a variable inside a target
&
an Movaqar
Sent: Tuesday, September 26, 2023 12:11 PM
To: Ed L Wolf ; bug-make@gnu.org
Subject: Re: Problem setting a variable inside a target
EXTERNAL SENDER: This email originated outside of Cummins. Do not click links
or open attachments unless you verify the sender and know the content is safe
_SETUP)/McData-copyright-can.a2l
> $(DIR_A2LGEN_SETUP)/McData-setup.a2l
> @echo "A2L Supplier folder not available"
> endif
>
> Ed L Wolf
> Technical Advisor - Embedded Software
> e.l.w...@cummins.com
> Cummins Inc.
> Mail Code: C7004
> 1460
On Sun, 2023-09-24 at 17:23 +, Ed L Wolf wrote:
>
> ifneq ($(wildcard $(DIR_SUPPLIER)),)
> ...
> > $(eval SUPPLIER_A2l := $(sort $(shell find $(DIR_A2LGEN_SUPPLIER) -
> > type f -name "*.a2l")))
> ...
> ifeq ($(SUPPLIER_A2l),"*.a2l")
>
Quickly skimming through your co
o "A2LSupplier folder not available"
endif
Ed L Wolf
Technical Advisor - Embedded Software
e.l.w...@cummins.com
Cummins Inc.
Mail Code: C7004
1460 National Road
Columbus, Indiana 47201
United States
-Original Message-
From: Bahman Movaqar
Sent: Tuesday, September 26, 2
Subject: RE: Problem setting a variable inside a target
* EXTERNAL EMAIL *
One more comment. For some reason SUPLLIER_A2l is blank
Ed L Wolf
Technical Advisor - Embedded Software
e.l.w...@cummins.com
Cummins Inc.
Mail Code: C7004
1460 National Road
Columbus, Indiana 47201
United States
@gnu.org
Subject: RE: Problem setting a variable inside a target
The following code response was
Supplier folder detected
Supplier folder detected but no a2l files present
but the response should have been
Supplier folder detected
Supplier
@gnu.org
Subject: Re: Problem setting a variable inside a target
EXTERNAL SENDER: This email originated outside of Cummins. Do not click links
or open attachments unless you verify the sender and know the content is safe.
> The eval statement below highlighted in red is not working
Perhaps yo
> The eval statement below highlighted in red is not working
Perhaps you'd expect to see "BADGER is wombat" from:
mad@shuttle:~/tmp/wolf-2023-09-24$ cat Makefile
default:
$(eval BADGER = wombat)
ifeq ($(BADGER),wombat)
echo BADGER is wombat
else
echo BADGER is not wombat
endif
m
On Wed, 2014-06-11 at 13:45 -0400, Paul Smith wrote:
> Unfortunately in older versions of make the option and argument
> are left as two separate words:
>
> $ echo 'a:;: $(MAKEFLAGS)' | make-3.81 -f- -I/usr/include -I/bin
> : I /usr/include -I /bin
>
> which makes it much more difficult to re
On Tue, 2014-06-10 at 16:01 -0700, Corey Brenner wrote:
> I've run into a situation where I want to control the include dirs in
> a recursive make. I am adding include paths to recursive invocations
> via --include-dir=, when I find one which matches my criteria.
>
> However, GNU Make seems to b
On 21.10.2010 21:04, Mike Shal wrote:
On Thu, Oct 21, 2010 at 1:33 PM, Vardhan, Sundara (GE Energy)
wrote:
Hi Michael
During parallel makes if the time of the object files created and the
time archive command is run is within a second then it will fail to
include these object files. The reaso
> Date: Thu, 21 Oct 2010 15:04:20 -0400
> From: Mike Shal
> Cc: Bug-make@gnu.org
>
> I don't see why Michael's example should fail, but I can reproduce the
> behavior with 3.81 and 3.82.
It fails because, depending on the timing, app1.o may or may not exist
when Make comes to check it. Here's t
On Thu, Oct 21, 2010 at 1:33 PM, Vardhan, Sundara (GE Energy)
wrote:
> Hi Michael
>
> During parallel makes if the time of the object files created and the
> time archive command is run is within a second then it will fail to
> include these object files. The reason I believe is due to a bug in ma
Hi Michael
During parallel makes if the time of the object files created and the
time archive command is run is within a second then it will fail to
include these object files. The reason I believe is due to a bug in make
rules wherein the time granularity is 1 second. Try to introduce a sleep
of
Title: Oracle Signature
I think you are misunderstanding what this syntax means:
a b c d e:
some_command
This does not indicate that 'some_command' will produce all of these
targets. Rather, it is short hand for this:
a:
some_command
b:
some_command
c:
some_command
d:
some
On Mon, 2008-04-21 at 15:17 +0530, vasanthan wrote:
> where could i found the same version of GNU make
> can any1 send me the link
Source code for GNU make can be found here:
ftp://ftp.gnu.org/gnu/make
--
-
That sounds unlikely to be a bug with make, so the help-make list would
be more appropriate. The make maintainer has a paper on dependencies
which you can find here:
http://web.archive.org/web/20061205233409/http://make.paulandlesley.org/
autodep.html
That focuses on automatic generation of the
On 04 August 2007 00:08, Christopher Faylor wrote:
> On Sat, Aug 04, 2007 at 01:08:54AM +0300, Eli Zaretskii wrote:
>>> Date: Fri, 3 Aug 2007 14:55:15 -0700 (PDT)
>>> From: [EMAIL PROTECTED]
>>>
>>> oops, here is the attached console capture
>>
>> It's much better to send this as plain text (you
On Sat, Aug 04, 2007 at 01:08:54AM +0300, Eli Zaretskii wrote:
>> Date: Fri, 3 Aug 2007 14:55:15 -0700 (PDT)
>> From: [EMAIL PROTECTED]
>>
>> oops, here is the attached console capture
>
>It's much better to send this as plain text (you can capture it with
>`tee' or even by copying and pasting the
> Date: Fri, 3 Aug 2007 14:55:15 -0700 (PDT)
> From: [EMAIL PROTECTED]
>
> oops, here is the attached console capture
It's much better to send this as plain text (you can capture it with
`tee' or even by copying and pasting the contents into your mailer).
My crystal ball says that somehow the co
> Date: Fri, 3 Aug 2007 14:52:53 -0700 (PDT)
> From: [EMAIL PROTECTED]
>
> I am trying to configure GNU make from cygwin and ./configure doesn't run.
> I have attached the cygwin console capture with the error.
I see no attachments.
___
Bug-make maili
Gupta, Sonia (Product Engineering Services, Mumbai) writes:
> While doing qmake calculator.pro we get an error Qfile:: file not
> specified.atleast 100 times. Can you tell us why is that.
No. This list is for discussion of bugs and issues with building and
using GNU make itself.
First, un
28290911
Mobile 9820522836
-Original Message-
From: Sam Ravnborg [mailto:[EMAIL PROTECTED]
Sent: Friday, July 27, 2007 4:10 PM
To: Tawade, Laxman
Cc: bug-make@gnu.org; Gupta, Sonia (Product Engineering Services,
Mumbai)
Subject: Re: problem
On Fri, Jul 27, 2007 at 12:13:16PM +0530, Laxman
On Fri, Jul 27, 2007 at 04:13:57PM +0530, Gupta, Sonia (Product Engineering
Services, Mumbai) wrote:
> Hi,
> While doing qmake calculator.pro we get an error Qfile:: file not
> specified.atleast 100 times. Can you tell us why is that.
I can only tell this is not a make error.
So please direct you
On Fri, Jul 27, 2007 at 12:13:16PM +0530, Laxman wrote:
> Hi,
>
>
>
> While creating a executable for x86 target - Lynx OS found following error
>
>
>
>
>
> Reading makefiles...
> Updating goal targets
> File `first' does not exist.
>File `all' does not exist.
> File `cal
On Fri, 2007-07-13 at 11:00 +0530, Anantharamaiah Bhaskara wrote:
> make T1 clean T2
>
> I expect
> 1. pre-requisites of T1 get built and then T1 itself
> 2. pre-requisities of T1 & T2 (common to both) get removed
> 3. pre-requisites of T2 get built and then T2 it
Hi,
[EMAIL PROTECTED] elucidated on 08/02/07 21:53:
i have some old (circa 1997) makefiles which run fine on current UNIX systems
with their versions of make. if i run gnu make as make -n then GNU make shows
the commands that will be executed just fine however, when i actually issue
the make c
On Tue, 2006-12-12 at 06:29 +0200, Eli Zaretskii wrote:
> But this test could be defeated if CURDIR was defined in the
> environment, right? If so, the test should make sure CURDIR doesn't
> come from the environment.
I was assuming that if it was defined, someone set it. But I guess
you're rig
> From: Paul Smith <[EMAIL PROTECTED]>
> Date: Mon, 11 Dec 2006 19:42:51 -0500
> Cc: bug-make@gnu.org
>
> This test is kind of strange. Unless there's some specific reason the
> makefile REQUIRES the CURDIR variable to be set by make, it should be
> rewritten:
>
> ifndef CURDIR
> $(error Please
On Mon, 2006-12-11 at 15:36 +0100, Sombat Ketrat wrote:
> the error msg. is
> ---
> GNUmakefile:3: *** Sorry, your version of GNU make (3.81) is too old.
> You need one that defines the CURDIR variable. Stop.
> ---
> ifneq (default,$(origin CURDIR))
> $(error Sorry, your version of GNU make ($(M
> Date: Mon, 27 Mar 2006 23:05:41 +0200
> From: [EMAIL PROTECTED]
>
> I'm using gnumake 3.78 (also tried 3.8) buided with VC on W2000.
> I've a problem with overriding default SHELL value from sh.exe to cmd.exe.
Yes, this is a known problem with Make on Windows. I believe it has
been corrected i
%% Anand Avati <[EMAIL PROTECTED]> writes:
aa> i do read a changelog entry in 2002-04-28 telling that exp_count
aa> contains max number of recursive calls allowed. but i do not
aa> understand why $(CMD) gets set with exp_count=0 while $(call CMD)
aa> gets set with exp_count=EXP_COUNT_MAX..
> Can you explain me why the del command can not be found?
del is part of cmd.exe, not a separate program. cmd /c del *.h will work. rm
*.h will probably work (if you have enough of cygwin installed to run make,
then you probably have rm).
> I have a problem with gmake.
This list is really f
%% "vivek" <[EMAIL PROTECTED]> writes:
v> When 'make' program is invoked with -C option, then it decends into
v> that directory but the 'PWD' variable still refers to the path from
v> where the 'make' was invoked rather than the path of the directory
v> it decends into.
PWD is not a varia
OK, a fix has been committed to CVS for this bug.
--
---
Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
"Please remain calm.
Hi Art,
This morning I did a 'cvs update', rebuild, and installation of make,
and am seeing a problem when trying to build the current GCC snapshot.
The 'make' command bombs out at the point where the GCC build process
prints out 'Bootstrapping the compiler'. Unfortunately I've deleted my
build log
I've rebuilt 'make' with debugging info and started a GCC build. The
build failed as expected and I've got a core file to examine. Make dies
in the record_files() function in read.c at line 1918. The 'this' variable
is null, so 'this->name' fails.
$ gdb make core
...
1918 if (fin
On Mon, Feb 28, 2005 at 04:28:01PM -0500, Paul D. Smith wrote:
> %% "Art Haas" <[EMAIL PROTECTED]> writes:
>
> ah> This morning I did a 'cvs update', rebuild, and installation of
> ah> make, and am seeing a problem when trying to build the current GCC
> ah> snapshot.
>
> I haven't seen this
%% "Paul D. Smith" <[EMAIL PROTECTED]> writes:
%% "Art Haas" <[EMAIL PROTECTED]> writes:
ah> This morning I did a 'cvs update', rebuild, and installation of
ah> make, and am seeing a problem when trying to build the current GCC
ah> snapshot.
pds> I haven't seen this, but I haven't tried t
%% "Art Haas" <[EMAIL PROTECTED]> writes:
ah> This morning I did a 'cvs update', rebuild, and installation of
ah> make, and am seeing a problem when trying to build the current GCC
ah> snapshot.
I haven't seen this, but I haven't tried to build gcc recently. Which
snapshot (3.3.x, 3.4.x, o
Paul D. Smith <[EMAIL PROTECTED]> writes:
> Anyway, the idea was certainly performance: if a directory doesn't exist
> and there are no rules in your makefile to create it (that is, there are
> no targets that allow make to create that directory), then in make's
> model it can never exist, so re
%% Boris Kolpackov <[EMAIL PROTECTED]> writes:
bk> If /tmp/out exists (/tmp/out/bin and /tmp/out/obj do not exist)
bk> then everything works file. When /tmp/out does not exist make
bk> fails. I have to idea about the logic behind this.
I assume you meant to say "no idea" :).
Anyway, the id
Juergen Schmidt <[EMAIL PROTECTED]> writes:
> has anybody an idea on this or can help me?
I am not sure this will actually help you but here it goes.
GNU make makes some strange guesses (see make.c around line 99) when it
comes to files in directories that do not exist. Consider for example
th
hi,
has anybody an idea on this or can help me? I would be glad to know if i
make something wrong or if it is maybe a make problem.
Thanks in advance
Juergen
Juergen Schmidt wrote:
Hi,
i have problem with make when i try to generate the output anywhere
and using an absolute path. Please see my s
This is a bug in GNU make 3.79.1. It's been fixed in newer versions.
--
---
Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
Hi,
May I suggest you read the manual section "5.3 Parallel Execution":
http://www.gnu.org/software/make/manual/make.html
If you still have problems provide all the details and I will try to help.
Regards
JG
on the 17/04/04 11:43, Nandkumar Sambhaji Gophane wrote:
Hi ...
I am learn
paul>> It's very easy, though, just do this:
paul>> DBG_ORDER = $(foreach V,$(RAW_DBG_ORDER),$($(V)))
paul>> You can make a function out of it and use $(call ...) if that makes it
paul>> clearer in your makefile.
Thank you, works like a charm.
--Duane
__
%% Duane Ellis <[EMAIL PROTECTED]> writes:
de> DBG_ORDER=$(RAW_DBG_ORDER:%=$(%))
de> REL_ORDER=$(RAW_REL_ORDER:%=$(%))
You can't do this: patterns don't replace before expansion, they replace
after expansion.
It's very easy, though, just do this:
DBG_ORDER = $(foreach V,$(RAW_DBG_ORDER),$
%% Dusan Turk <[EMAIL PROTECTED]> writes:
dt> I am running into strange kind of a problem with "make" on
dt> $ make -v
dt> GNU Make version 3.79.1, by Richard Stallman and Roland McGrath.
dt> Argument #6 of `reflect_set_calc' is one type at (2) but is some other
dt> type at (1) [inf
%% Helmut Dipper <[EMAIL PROTECTED]> writes:
hd> -include aaa
hd> sinclude bbb
hd> .DEFAULT:
hd> @echo "target: $@"
hd> #--
hd> and the results:
hd> target: bbb
hd> target: aaa
hd> gmake: *** No targets. Stop.
hd> How can it b
On Thu, 19 Dec 2002, Matt Hodges wrote:
>> Ted Stern writes:
>
> > Interesting. For the bash test, try
>
> > SHELL := /bin/bash --noprofile --norc
>
> > If that doesn't work, try adding --posix.
>
> The --norc option makes it work.
This should tell you something -- something is
> Paul D Smith writes:
> I can't imagine what the problem might be... certainly bash works
> fine for me with GNU make on Linux and Solaris...
Something really strange is happening. There seems to be some random
variation in the results. For this Makefile:
-
> Ted Stern writes:
> Interesting. For the bash test, try
> SHELL := /bin/bash --noprofile --norc
> If that doesn't work, try adding --posix.
The --norc option makes it work.
> You might also want to try running the makefile from within a
> non-bash interactive shell, e.g. /bi
I can't imagine what the problem might be... certainly bash works fine
for me with GNU make on Linux and Solaris...
--
---
Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at:
http://www.gnu.org
> Ted Stern writes:
> > I'm having problems building a program on Digital UNIX V4.0F, and
> > it seems to boil down to the following observed behaviour on this
> > platform. The results from issuing `make' with this makefile:
> What happens if you specify
> SHELL := /bin/ksh
OK, h
On Wed, 18 Dec 2002, Matt Hodges wrote:
>> Ted Stern writes:
>
> > > I'm having problems building a program on Digital UNIX V4.0F, and
> > > it seems to boil down to the following observed behaviour on this
> > > platform. The results from issuing `make' with this makefile:
>
> > What hap
On Wed, 18 Dec 2002, Matt Hodges wrote:
> I'm having problems building a program on Digital UNIX V4.0F, and it
> seems to boil down to the following observed behaviour on this
> platform. The results from issuing `make' with this makefile:
What happens if you specify
SHELL := /bin/ks
Please try with the latest version of GNU make (3.80).
--
---
Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
"Please remain
Whoops; I see it.
Fixed. Thanks for the report.
--
---
Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at:
http://www.gnu.org http://make.paulandlesley.org
"Please remain calm
-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: Thursday, September 12, 2002 7:39 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Problem with GCC and Make
Please choose only one of help-make or bug-make.
This is a problem with the configure script
Please choose only one of help-make or bug-make.
This is a problem with the configure script generated by the version of
autoconf used by GNU make 3.79.1, HP-UX 11, and GCC 3.x. The next
version of GNU make will fix this.
If you don't want to wait you can get a pretest of the next version in:
No.
There is only one issue I know of with the implementation of the
jobserver in 3.79.1: it allows signals to interrupt system calls
throughout the program. This can impact things like readdir(), etc.
But, while this does cause some problems sometimes I've never known it
to cause a jobserver h
Title: RE: problem with parallel builds on AIX
No I don't think it was spinning.
Just to make sure I'm not misinterpreting what you meant:
Is waiting for tokens to appear a known problem?
Regards,
Per
-Original Message-
From: Paul D. Smith [mai
%% "Olausson, Per-Anders" <[EMAIL PROTECTED]> writes:
op> Is there a known problem with running parallel builds on AIX?
Not that I'm aware of.
op> Unfortunately, I have not yet made a core of the processes or
op> observed whether the jobserver is spinning or not
Likely it's waiting for
Make does not deal with backslashes very well at all. This is discussed
already in the README.W32 file, etc.
It is a known issue but one for which there is no trivial solution:
backslashes in UNIX (and make) typically are escape characters.
I will give you the same advice that the README files,
Sorry, but you'll need to check with the Perl folks about this. It
seems like the makefile that Perl is generating from Makefile.PL isn't
correctly formatted.
The only suggestion I can give, from a make standpoint, is to try a
newer version of GNU make. 3.77 is pretty old; the latest version is
My recollection is that this is a "feature" of AIX: GNU make never
touches any of these environment variables.
If you install a program as SUID or SGID, then the system will unset
these variables itself.
By default GNU make installs with the setgid bit set on AIX in order to
be able to determine
Yes, this is a known bug. It will be fixed in the next release.
There's a patch around I can forward to you in the meantime, if you like
(it's also available in the archives of this list I'm sure...)
--
---
Paul D. Smi
%% "Nic Ferrier" <[EMAIL PROTECTED]> writes:
nf> I think I've found a problem with version 3.79.1 of make. The
nf> problem also exists with 3.78.1
nf> The problem is that the $(wildcard) function doesn't always work. If
nf> the file that is tested only exists as the result of an operatio
On Sun, 29 Apr 2001 15:00:51 +0200, Neta Bar Tal <[EMAIL PROTECTED]>
wrote:
>Hi there!
>when i use GNU make with the -j flag, all the output of the process
>(compiling in parallel) is mixed together,
>what can I do in order to avoid this situation (maybe I should flush the
>buffers in each child
%% Neta Bar Tal <[EMAIL PROTECTED]> writes:
nbt> when i use GNU make with the -j flag, all the output of the process
nbt> (compiling in parallel) is mixed together,
nbt> what can I do in order to avoid this situation (maybe I should flush the
nbt> buffers in each child process, but I don'
GNU make 3.77 is a number of years old; many bugs have been fixed since
it was released.
Please try the latest version (3.79.1) and let us know if there are
still issues.
Thanks.
--
---
Paul D. Smith <[EMAIL PROTECTED
I wrote:
> Add the line:
>
> AC_CHECK_HEADER(locale.h)
^^^
There is an 'S' missing above. The line has to look like that:
AC_CHECK_HEADERS(locale.h)
ciao
Klaus Heinz
___
Bug-make mailing list
[EMAIL PROTECTED]
http://mail.
This is known bug PR/1831. See the README, etc. for information on
accessing the online bug database for GNU make.
--
---
Paul D. Smith <[EMAIL PROTECTED]> Find some GNU make tips at:
http://www.gnu.org
%% Alan Heinold - High End Server Systems <[EMAIL PROTECTED]> writes:
ah> I bet the answer is very simple but I can't get it to work
ah> given the following make file:
ah> %.build: %.att %.guidance
ah> @echo "Done testing."
ah> %.att:
ah> @ echo "gmake[$(MAKELEVEL)]: $@ does not
%% [EMAIL PROTECTED] writes:
d> I downloaded the GNU make 3.77 from sourceware.cygnus.com/cygwin.
d> I use the following makefile:
Wait, I lied :(.
I think this bug is because your makefile has DOS/Windows style CRLF
newlines, instead of UNIX style LF newlines.
GNU make prior to 3.78 didn'
%% [EMAIL PROTECTED] writes:
d> I downloaded the GNU make 3.77 from sourceware.cygnus.com/cygwin.
d> I use the following makefile:
d> I get the following error message:
d> ', needed by `hello'. Stop.e target `hello3.c
This is a memory corruption bug, that has been fixed in later versio
%% "Randall J . Million" <[EMAIL PROTECTED]> writes:
rjm> I have been unable to assertain why GNU make cannot handle the
rjm> following file, while the AIX default make handles it just
rjm> fine.
rjm> y.tab.o lex.yy.o: $(@:.o=.c)
This syntax isn't supported by GNU make (actually, this s
%% Volker Borchert <[EMAIL PROTECTED]> writes:
vb> I am experiencing test failures on both NetBSD-1.4.2/sun3x and
vb> OpenBSD-2.3/sparc. The symptom is that the output (STDOUT/STDERR)
vb> log files contain lots and lots of rubbish, mostly nulls.
Yuck! I haven't had any reports like that.
You've given a lot of good info here, but you're missing the most
important part: a sample of the makefile rule you used to invoke the
recursive make.
I'll bet it looks something like:
subdir:
cd subdir; $(MAKE) $(MAKEFLAGS)
That's an incorrect use of MAKEFLAGS. See the GNU make manu
%% Regarding Problem with .INTERMEDIATE;
%% "Chris Rankin" <[EMAIL PROTECTED]> writes:
cr> We are seeing the following problem with GNU make versions 3.77
cr> and 3.78.1 (Makefile below):
cr> $ make bug.o
cr> gcc-c -o bug.o bug.c
cr> rm bug.o
cr> In other words, although we are
On Wed, Mar 22, 2000 at 01:43:56PM +1100, Chris Rankin wrote:
> Hi,
>
> We are seeing the following problem with GNU make versions 3.77 and 3.78.1 (Makefile
>below):
>
> $ make bug.o
> gcc-c -o bug.o bug.c
> rm bug.o
>
> In other words, although we are *explicitly* requesting that this fil
Here it is (note I haven't tried it myself):
>From: Warren Jones <[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: case-insensitive globbing (patch for 3.78.1)
>Date: Thu, 3 Feb 2000 09:50:05 -0800
>
>If HAVE_CASE_INSENSITIVE_FS is defined under Win32, file name
>globbing should also be case-i
>
> I actually have a patch for the glob library that fixes this problem
> (makes globbing aware of the HAVE_CASE_INSENSITIVE_FS macro).
>
> The small issue here is that the glob code in make is
> actually extracted
> verbatim from the GLIBC library, so any change to it actually
> has to be
>
I actually have a patch for the glob library that fixes this problem
(makes globbing aware of the HAVE_CASE_INSENSITIVE_FS macro).
The small issue here is that the glob code in make is actually extracted
verbatim from the GLIBC library, so any change to it actually has to be
forwarded to them for
86 matches
Mail list logo
