Bug 38715 - gcc 4.4.0 20090102 - tools/Makefile using a non portable find option
gcc 4.4.0 20090102 - tools/Makefile using a non portable find option
Status: RESOLVED FIXED
Product: classpath
Classification: Unclassified
Component: cp-tools
unspecified
: P3 normal
: ---
Assigned To: Not yet assigned to anyone
:
: 39925 41899 42120 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-01-03 11:59 UTC by Rob
Modified: 2010-09-30 15:52 UTC (History)
7 users (show)

See Also:
Host: *-*-solaris2.*
Target: *-*-solaris2.*
Build: *-*-solaris2.*
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Rob 2009-01-03 11:59:05 UTC
In Bug 23653 Eric complains that "-path" is not a portable option for "find".

Eric was getting stuck at "Making all in lib" and titled his report 
"lib/Makefile is not portable". 

I will call my Bug Report "gcc 4.4.0 20090102 - tools/Makefile is not portable".


Here is where the build breaks:

gmake[6]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava/classpath/scripts'
Making all in tools
gmake[6]: Entering directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava/classpath/tools'
Makefile:839: warning: overriding commands for target `gjdoc'
Makefile:774: warning: ignoring old commands for target `gjdoc'
find ../../../../../../gcc_trunk/libjava/classpath/tools/external/asm -name '*.java' -print > asm.lst
find ../../../../../../gcc_trunk/libjava/classpath/tools/gnu/classpath/tools \
	     ../../../../../../gcc_trunk/libjava/classpath/tools/com/sun/javadoc \
	     ../../../../../../gcc_trunk/libjava/classpath/tools/com/sun/tools/doclets \
	     ../../../../../../gcc_trunk/libjava/classpath/tools/com/sun/tools/javadoc \
	     ../../../../../../gcc_trunk/libjava/classpath/tools/com/sun/tools/javac \
	     ../../../../../../gcc_trunk/libjava/classpath/tools/com/sun/tools/javah \
	     ../../../../../../gcc_trunk/libjava/classpath/tools/sun/rmi/rmic \
	     -path '*gnu/classpath/tools/gjdoc' -prune -o -path '*gnu/classpath/tools/doclets' -prune -o -path '*gnu/classpath/tools/taglets' -prune -o -path '*com/sun/javadoc' -prune -o -path '*com/sun/tools/doclets' -prune -o -path '*com/sun/tools/javadoc' -prune -o \
	     -name '*.java' -print > classes.lst
find: bad option -path
find: [-H | -L] path-list predicate-list
gmake[6]: *** [tools.zip] Error 1
gmake[6]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava/classpath/tools'
gmake[5]: *** [all-recursive] Error 1
gmake[5]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava/classpath'
gmake[4]: *** [all-recursive] Error 1
gmake[4]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava'
gmake[3]: *** [multi-do] Error 1
gmake[3]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/libjava'
gmake[2]: *** [all-multi] Error 2
gmake[2]: Leaving directory `/usr/share/src/gcc_build/i386-pc-solaris2.11/libjava'
gmake[1]: *** [all-target-libjava] Error 2
gmake[1]: Leaving directory `/usr/share/src/gcc_build'
gmake: *** [all] Error 2

Thanks,
Rob
Comment 1 Andrew Pinski 2009-01-13 00:51:00 UTC
@CREATE_GJDOC_FALSE@GJDOC_EX = -path '*gnu/classpath/tools/gjdoc' -prune -o \

Comment 2 Andrew Pinski 2009-01-13 00:54:05 UTC
This was introduced between 2008-08-12 and 2008-10-20.
Comment 3 Rob 2009-02-09 14:12:57 UTC
This error occurs in OpenSolaris 2009.06 as well (which is also identified as: i386-pc-solaris2.11 ).

# uname -a
SunOS opensolaris 5.11 snv_106 i86pc i386 i86pc

# isainfo -k (don't use "uname -m")
amd64

Thanks,
Rob
Comment 4 Andrew Pinski 2009-04-28 14:16:44 UTC
*** Bug 39925 has been marked as a duplicate of this bug. ***
Comment 5 Hin-Tak Leung 2009-07-28 20:39:44 UTC
same problem with gcc 4.4.1 on alphaev68-dec-osf5.1a - surely this is regarded as a regression as 4.3.x doesn't do this. According to the man page, 'Tru64 find' conforms to XCU5.0, which is

X/Open CAE specifications XBD, XCU, and XSH, Issue 5, 1997 (XBD5.0, XCU5.0, and XSH5.0)

I presume the X/Open specification quoted is available somewhere.
Comment 6 Peter O'Gorman 2009-09-13 06:20:29 UTC
(In reply to comment #5)
> I presume the X/Open specification quoted is available somewhere.
> 

http://www.opengroup.org/onlinepubs/009695399/utilities/find.html

That's not quite the latest version of the spec, but no -path there.
Comment 7 Andrew Pinski 2009-11-01 21:10:36 UTC
*** Bug 41899 has been marked as a duplicate of this bug. ***
Comment 8 Dr. David Kirkby 2009-11-01 21:36:04 UTC
(In reply to comment #6)
> (In reply to comment #5)
> > I presume the X/Open specification quoted is available somewhere.
> > 
> 
> http://www.opengroup.org/onlinepubs/009695399/utilities/find.html
> 
> That's not quite the latest version of the spec, but no -path there.
> 

The 2008 edition of the POSIX spec is available online.

http://www.opengroup.org/onlinepubs/9699919799/utilities/find.html

and -path is not in that either. But in any case, I personally believe that even if -path were in the 2008 POSIX  spec, but not the 2004 POSIX spec, -path should not be used. Expecting people to have all the latest standards is a bit unreasonable. 

On OpenSolaris, it's possible to download 'SUNWgnu-findutils' with the Package manager. 

  Summary:		 GNU utilities find and xargs
  Size:			 769.50 kB
  Category:		 Applications/System Utilities
  Installed Version:	 0.5.11,5.11-0.111
  Latest Version:	 0.5.11,5.11-0.111
  Packaging Date:	 Fri May  8 16:05:46 2009
  FMRI:			 pkg:/SUNWgnu-findutils@0.5.11,5.11-0.111:20090508T160546Z
  Repository:		 opensolaris.org

On Solaris 10, I do not believe there is any easy way around this - you would probably need to use Blastwave, Sunfreeware or compile from source. 

On OpenSolaris I got around the issue by downloading the GNU findutils, copying 'find' to /tmp and adding that in my path. 

drkirkby@hawk:~/gcc-4.4.2$ cp /usr/gnu/bin/find /tmp
drkirkby@hawk:~/gcc-4.4.2$ export PATH=/tmp:$PATH
drkirkby@hawk:~/gcc-4.4.2$ /opt/csw/bin/gmake 

But it would be much better to get rid of the GNUism. I would like to build gcc on HP-UX, and no doubt will hit exactly the same issue there. 

Dave 
Comment 9 Dr. David Kirkby 2009-11-01 21:48:41 UTC
(In reply to comment #3)
> This error occurs in OpenSolaris 2009.06 as well (which is also identified as:
> i386-pc-solaris2.11 ).

Just to reiterate a point I have made in #41899 which was marked a duplicate of this, if any *serious* GCC developer needs access to Solaris machines running on SPARC or x86 hardware, I can arrange that. Sun donated a Sun T5240 to the Sage project

http://www.sagemath.org/

which can be used for any development of code used in Sage, which includes gcc of course. 

There are also OpenSolaris machines, where I can arrange access. That might have to be a virtual machine running on a linux host, but it might be possible to use a Solaris one too. (The Solaris x86 machine is a server, so we are less inclined to use that for development purposes). 

Just drop me a private email if you need access. This is only open to those that are seriously developing code - not anyone that happens to fancy playing on a 16 core machine for a bit of fun!

Dave 
Comment 10 Andrew Pinski 2009-11-20 16:36:05 UTC
*** Bug 42120 has been marked as a duplicate of this bug. ***
Comment 11 Ralf Wildenhues 2010-09-24 18:04:45 UTC
Fixed in trunk and 4.5 by r156023
http://gcc.gnu.org/ml/gcc-cvs/2010-01/msg00489.html
backport to 4.4 in r160171
Comment 12 Rob 2010-09-30 15:52:40 UTC
(In reply to comment #11)
> Fixed in trunk and 4.5 by r156023
> http://gcc.gnu.org/ml/gcc-cvs/2010-01/msg00489.html
> backport to 4.4 in r160171

Ralf, Thank you for fixing that 20 month old Bug !

Reporter,
Rob