mohawk2 / dmake Goto Github PK

Failing build (make phase) on Cygwin64

gcc  -g -O2   -o dmake.exe infer.o make.o stat.o expand.o dmstring.o hash.o dag.o dmake.o path.o imacs.o sysintf.o parse.o getinp.o quit.o state.o dmdump.o macparse.o rulparse.o percent.o function.o  unix/arlib.o unix/dcache.o unix/dirbrk.o unix/rmprq.o unix/ruletab.o unix/runargv.o unix/tempnam.o
path.o: In function `normalize_path':
/cygdrive/c/integration/src/dmake/path.c:320: undefined reference to `cygwin_conv_to_posix_path'
/cygdrive/c/integration/src/dmake/path.c:320:(.text+0x6dd): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `cygwin_conv_to_posix_path'
sysintf.o: In function `Prolog':
/cygdrive/c/integration/src/dmake/sysintf.c:548: undefined reference to `cygwin_conv_to_posix_path'
/cygdrive/c/integration/src/dmake/sysintf.c:548:(.text+0x677): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `cygwin_conv_to_posix_path'
sysintf.o: In function `cygdospath':
/cygdrive/c/integration/src/dmake/sysintf.c:1158: undefined reference to `cygwin_conv_to_win32_path'
/cygdrive/c/integration/src/dmake/sysintf.c:1158:(.text+0x126b): relocation truncated to fit: R_X86_64_PC32 against undefined symbol `cygwin_conv_to_win32_path'
collect2: error: ld returned 1 exit status
make[2]: *** [Makefile:555: dmake.exe] Error 1
make[2]: Leaving directory '/cygdrive/c/integration/src/dmake'
make[1]: *** [Makefile:626: all-recursive] Error 1
make[1]: Leaving directory '/cygdrive/c/integration/src/dmake'
make: *** [Makefile:397: all] Error 2

I got rid of this by commenting out following:

/* int err = cygwin_conv_to_posix_path(path, cpath);
      * if (err)
	 *Fatal( "error converting \"%s\" - %s\n",
		* path, strerror (errno));
		*/

in path.c and in similar way in other files.

I think these cygwin_* functions are obsolete, aren't they?

What steps will reproduce the problem?

1. make check

What is the expected output? What do you see instead?

Expected:
PASS: misc-13

Actual output:
Wrong result: Checking prerequisite [.TARGETS]
Checking prerequisite [TeSt.target]
dmake: Time stamp of [TeSt.target] is 1336952881
dmake: >>>> Making [TeSt.target]
dmake: Up to date [TeSt.target], prq time = 1 , target time = 1336952881)
dmake: >>>> Making [.TARGETS]
dmake: Updating [.TARGETS], (1336952881 > 0)
dmake: <<<< Set [.TARGETS] time stamp to 1336952881
dmake: >>>> Making [.ROOT]
dmake: Updating [.ROOT], (1336952881 > 0)
dmake: <<<< Set [.ROOT] time stamp to 1336952881
`TeSt.target' is up to date
Failure!
FAIL: misc-13

What version of the product are you using? On what operating system?

dmake-4.12.2 on Gentoo Linux
This appears to be a regression from 4.12

Please provide any additional information below.

Additional test failure due to targets-{1..12} not marked as executable, but this is not a regression and unrelated to the issue here.

build.log

22.0 KB View Download
Jun 10, 2012
Project Member # 1 [email protected]

The problem is reproducible on FreeBSD.

It also happens on 4.12 so it's not really a regression.

Status: Accepted
Labels: -Priority-Medium Priority-Low
Jul 31, 2012
#2 [email protected]

The misc-13 test passes on dmake-4.12 on Gentoo, so it is a regression here.

this is a followup to issue 85014.

taking the same sample makefile and commandline

- - - makefile.mk - - -
SHELL:=cmd.exe 
SHELLFLAGS:=/S /C

all : exists
    @echo Done

exists ::
    +@echo create > $@
- - - makefile.mk - - -

$ rm exists && ./dmake/dmake.exe -rf ../t_shay_2mw.mk

the warning

dmake: Warning: -- Target [all] was made but the time stamp has not been updated.

occurs when building on a network volume (smb or nfs) or a local fat32 volume...

dmake 4.12 on the below makefile.mk fails with "`b:' not found, and can't be
made" as it apparently mis-parses the "{$X}:" part ("{$X} :" would work, but
dmake/man/dmake.nc states that "[the] rule operator [...] does not require white
space to precede or follow it").

X = a b

Y .PHONY : $X

a b :
        touch $@

{$X}: makefile.mk

I built dmake on Windows using mingw and msys. Used a patch similar to the msys patch listed here. I'm trying to work with the FHS standard to determine where files are placed under msys. When I built dmake, it placed the .mk files under usr\local\share\startup which makes sense and follows the FHS standard. When I run dmake, it's looking for the files in startup subdirectory beneath the bin directory where the dmake executable is (usr\local\bin\startup).

There's a line in configure that switches it to look for DMAKEROOT at $datarootdir/share/startup, but it's only set to work for unix like machines:

if test x$OS_TYPE = xunix; then
DMAKEROOT_H_LINE1='"DMAKEROOT := '${dmakerootprefix}'/startup",'
fi

Had to work around the issue with:

export MAKESTARTUP=\\mingw\\msys\\usr\\local\\share\\startup\\startup.mk

I like the fact that it installs support files in $datarootdir/share/. However, it would be even nicer if it could actually find the files that it installs to that directory. Thanks.

I have made a working Travis config. I would like a working appveyor config now. It seems AppVeyor offer MinGW and various Visual Studio installations in their standard build. I would like as many of the modern-ish Windows possibilities being tested.

Unfortunately getting MSVC into the path for command-line stuff has defeated me. The closest I have got is using vcvarsall.bat (from https://stackoverflow.com/questions/42855857/how-to-find-ms-c-c-compilers-in-appveyor), but it is saying it can't find the 'include' dirs, and indeed the winnt\microsft\vpp40\mk.cmd failed because it couldn't find headers.

@bulk88 @kmx Can you help with this at all?

Reported by [email protected], Nov 17, 2012

[What steps will reproduce the problem?]

1. Set up a cygwin-provisioned MS Windows system
2. Install the Mingw toolchain
3. Correctly configure PATH for precedence of Mingw tools
4. Unpack and configure src kit specified in Summary
5. Run make to build the project

[What is the expected output? What do you see instead?]
Expected: successful compilation
Observed: see attached scriptfile (build record from terminal) "gnuscript_build_dmake_exe_alone.nonascii.txt"

digest summary of (c compiler error) failure for web searches:
sysintf.c:156:3: error: #error "Utime NULL not supported"
sysintf.c: In function 'Do_touch':
sysintf.c:158: error: expected expression before '}' token

[What version of the product are you using? On what operating system?]
Product version: specified above.
OS: MS Windows "Starter Edition" with MingW toolchain (GCC-4.3) and
cygwin shell environment (NOT cygwin build environment) to provide
standard *nix functionality for a terminal session to build with, a
the basic *nix shell tools such as cp, mkdir, etc.

[Please provide any additional information below.]

Attachments 2 consists of "config.status" created under the build
environment described above.

GNU : Makefile.in generated by automake 1.9.6

Transferred from AOO bugzilla:
The patch contains fixes for this:

1. dmake is not able even start if it is installed in a directory containing
   spaces in directory name.

• I have to fix dmake itself (4-line patch of expand.c)
• but also startup/*.mk scripts (I have fixed just Windows related files)
• you might want to patch other (e.g. unix) *.mk files in a similar way

2. I have added a build batch for mingw32 enviroment - see newly added
   winnt/mingw/build.cmd + winnt/mingw/config.h

Please consider the patch, it would be nice if you can accept it an commit in
your SVN as we are using dmake in strawberry perl project
(http://www.strawberryperl.com) and do not want to keep any sort of unofficial dmake patches.

Thanks

kmx

Bad news, my patch does not work well with the following Makefile:

#########
LIST1   = a.a ../b.b ./c.c ..\d.d .\e.e /f.f \g.g c:/h/h.h c:\i\i.i
LIST2   = $(LIST1:f)

all:
    echo "LIST2=$(LIST2)"
#########

At the moment I have no idea how to fix it.

I would appreciate any help.

kmx

I have problem while configure dmake for mingw. Configure script doesn't correctly detect win platform. I attach patch for this issue

--- a/configure 2012-11-27 12:44:45 +0400
+++ b/configure 2012-11-27 12:12:26 +0400
@@ -4349,7 +4349,7 @@
OS_VERSION=cygwin
CASE_INSENSITIVE_FS=true
;;
- "MINGW")
+ MINGW*)
OS_VERSION=mingw
OS_TYPE=winnt
BUILDINFO="Windows / MinGW"

not sure if this is a feature that helps more that it creates confusion ;)
just for the record:

# doesn't work
#bla:=uuu:;\
#   echo hier
#
#$(bla)

ttt:;
    echo dort

Testcase:

foobar ?= VALUE:="plain-rule"
foobar_% ?= VALUE:="percent-rule"

foobar:
       echo "value $(VALUE)"

foobar_%:
       echo "value $(VALUE)"

running dmake foobar prints "value plain-rule" - but when running dmake
foobar_abc it prints "value " - so the Macro VALUE is not evaluated at
all.

changing the order to be

foobar_%:
       echo "value $(VALUE)"

foobar_% ?= VALUE:="percent-rule"

works as expected.

See the URL for the mail to dev@tools for reference

with dmake 4.7

lala:
    echo 1
    # comment
    echo 2

breaks with linux and 4nt (not cygwin ;)) version while

lala:
    echo 1
# comment
    echo 2

works fine

This is part of my effort to implement a rule cancel feature (see https://www.gnu.org/software/make/manual/html_node/Canceling-Rules.html ) in dmake to speed up perl world building by trimming irrelevant extensions from being stat()ed/executed CPU overhead for them like for fortran and pascal languages. My knowledge of the make language is very poor so there might be bad mistakes in the rest of this post.

%.obj : %.pas

produces

#====================================
# Dump of inference graph


%.obj : %.c 
    $(CC) $(CFLAGS) -c $<

%.obj : %.pas 
    $(PC) $(PFLAGS) -c $<

%.obj : %.asm 
    $(AS) $(ASFLAGS) $(<:s,/,\)

with warning

dmake:  newline:  line 3:  Warning: -- Empty recipe for special or meta target %.obj

while

%.obj : %.pas;

produces

#====================================
# Dump of inference graph


%.obj : %.c 
    $(CC) $(CFLAGS) -c $<

%.obj : %.pas 


%.obj : %.asm 
    $(AS) $(ASFLAGS) $(<:s,/,\)

with no warning.

Shouldn't these 2 statements be identical in make lang syntax? notice if the "dmake: newline: line 3: Warning: -- Empty recipe for special or meta target %.obj" warning fires, the already existing rule is left unmodified.

To implement the rule cancelling feature, I need to know what part of the dmake lang to change, since these are 2 different code paths ATM. Do these 2 code paths need to be unified into 1 code path? or do i implement the rule canceller only for the semicolon syntax, not newline+tab+newline syntax? and is the "issue warning and discard new definition, and keep old one" the correct behavior, or should the behavior for both be "dont issue a warning, accept the new definition"?

(from schwern)

Hi,
I maintain ExtUtils::MakeMaker that makes Makefiles to install Perl modules.
Since its an automated thing, and a bit long in the tooth, it sometimes creates
rather long lines. For example, http://gist.github.com/575964

I've been getting complaints about dmake rejecting long lines, even if they're
broken up by escaped newlines. I've just introduced a work around by setting
MAXLINELENGTH.

The whole concept strikes me as a memory optimization hack leaked out to the
user. It looks like dmake is allocating a fixed hunk of memory to concatenate
together lines of input, the size of that allocation is governed by
MAXLINELENGTH. This might have made sense back when 8k meant something.
Bumping the default up to 32k helped, but its still something users should not
have to deal with. I'm not aware of any other mainstream make implementation
that works this way (but boy are there OS' with some stingy exec lengths).

A more dynamic approach would seem to be in order. Allocate a string of size X
and realloc it to size * Y as needed. Perl uses a simple doubling heuristic, it
depends on the CPU cost of realloc vs how much memory you want to potentially waste.

Looking at the code, Buffer is used for a small number of things. Get_line(),
Parse_rule_def() and storing command line options in main() is all I see.
Parse_rule_def() just grabs at the global. The buffer is passed into Get_line()
which has no opportunity to inform the user that its been reallocated. I don't
know if Get_line()'s PUBLIC flag means its use is outside the control of dmake,
but its interface would have to change for this to work. Otherwise only Parse()
uses it.

If Get_line() is really public, as in published and used by code outside the
control of dmake, a new function could be written that does the reallocation as
necessary. Get_line() could be a wrapper which sets a flag that tells the new
function to throw an error rather than reallocate.

I realize this is a bit of rearchitecting, but I thought it should be brought
up. Thank you.

After

  mkdir -p test1/test2
  touch test1/foo
  cp ... test1/test2/makefile.mk # see below for content

dmake 4.12 on the below test1/test2/makefile.mk fails with "`a_foo' not found,
and can't be made".

X .PHONY: a_foo

a_%: '../../test1/foo'
        touch $@

The root of the problem is that the function normalize_path in dmake/path.c is
called on the string "'../../test1/foo'", does not handle the surrounding '...'
properly and instead erroneously collapse the leading "'.." path segment with
the following ".." path segment, causing normalize_path to return "test/foo'".
An experimental patch is

--- a/dmake/path.c
+++ b/dmake/path.c
@@ -310,7 +310,9 @@
     * list. As dynamic macro expression must not be normalized and is
     * indistinguishable from a literal $ characters at this point we skip
     * the normalization if a $ is found.  */
-   if( strchr(path, '$') ) {
+   if( strchr(path, '$') ||
+       ( path[0] == '\'' && path[strlen(path) - 1] == '/\'') )
+   {
       DB_RETURN( path );
    }

In issue 80368 it can be seen that it can be a problem that %-targets without prerequisites are not shown in ambiguous inference chains.

With the following attached makefile try:

$ ./dmake/dmake.exe -rf makefile.mk

There will be no indication that the lev2%.txt or lev2%.html targets are used for the inference chain.