United StatesChange Country, Oracle Worldwide Web Sites Communities I am a... I want to...
JDK-8001541 : build-infra: Cannot build on Solaris using softlinks

Submit Date:
Updated Date:
Project Name:
Resolved Date:
Affected Versions:
Fixed Versions:

Related Reports

Sub Tasks

Using the new and latest build-infra makefiles, using build-infra/jdk8 forest, 
On Solaris 11, if you run   "sh ./configure"  it does not create a "build/" directory and clobbers the files at the top of the repository.

hg clone http://hg.openjdk.java.net/build-infra/jdk8 myjdk8
cd myjdk8
sh ./get_source.sh
sh ./configure


Transitioned from Resolved to Closed / Not Verified on behalf of mikhail.kondratyev@oracle.com.
URL:   http://hg.openjdk.java.net/jdk8/jdk8/rev/754f91d22e1c
User:  katleman
Date:  2012-12-05 21:45:09 +0000

URL:   http://hg.openjdk.java.net/jdk8/build/rev/754f91d22e1c
User:  erikj
Date:  2012-12-05 13:28:16 +0000

I found two causes for problems in BASIC_REMOVE_SYMBOLIC_LINKS.

* The test for readlink used --help and grep:ed for GNU. On my solaris_sparc the gnu readlink didn't print "GNU" in the help message but only in --version. Changed to --version.
* The backup implementation failed for directory only symlinks. I reordered statements a bit and made it work. I also removed all -P to $THEPWDCMD since it isn't supported on all platforms and seems to remove symlinks anyway, on both solaris and linux. This differs from the shell builtin pwd which only resolves symlinks with -P. I also replaced plain `pwd` with $PWD which should work the same way, and be more obvious in asking for a non resolved directory.

This solution seems to work with /net/mymachine-paths too since the same pwd command is used to resolve the paths in all cases, comparisons work.
I can confirm that this is still a problem. The RE build on solaris sparc is failing to this and I just managed to reproduce myself. Will try to solve it now.
I have not been able to reproduce this with the current solution in build-infra. I have tried both symlinks and using /net in the path and it still works as expected. Could you see if this is still a problem, Kelly?
Assigning this to Erik, but I reduced it to a P2.  Erik may have fixed this or addressed it enough to close this, not sure.

Not sure how to deal with this the best way but priority #1 is that we should never clobber existing files, and I think that may have been fixed.

Normalizing all paths with pwd or /usr/bin/pwd does not help, that does get rid of softlinks but not the /net/*/ prefix issues for some reason. And the /net/ prefix can be spelled many different ways, all valid, and all meaning the same thing. I tried to sed out the /net/ prefix if "hostname" was after the /net/, but that sed command did not work when run from the m4 file for some reason. Tricky and convoluted, and I hate to see that get into our configure logic. I considered comparing inodes (ls -i) but felt that was diving too deep into the file system specifics.  Might be better to create a directory with a very unique name, then check to see if that directory exists via the other path.  Just ideas...

Lowered to P2.
Does "pwd -P" help? It should normalize the path.
Also, you might want to run the path through BASIC_REMOVE_SYMBOLIC_LINKS.

I have no idea with the /net prefix. I can't see a way to do that portable and without lots of assumptions. Maybe check with mount and see what /net/... is? But that sounds like lots of work, is this really such a common scenario that it's worth it?

Also, if you normalize all paths the same way, they should end up the same, even if it's in a /net directory. I'm surprised if it doesn't..?
I have tried various solutions and cannot find one.
This needs someone more familiar with m4 and autoconf.
But the general issue is that you cannot just compare paths for equality, something needs to know how to normalize them for the system, dealing with softlinks and this optional /net/`hostname`/ prefix.

It's not Solaris 11 but something to do with paths that have been resolved or not.
The configure logic is assuming to can just compare paths and you can't trust that to be right.



Hardware and Software, Engineered to Work Together