This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I ran into this while evaluating bug #172494. The SubProjects sample uses -R with a relative path: -R../hello3lib/dist/Debug/SunStudio-Solaris-Sparc This means that the application will not be able to find it's shared libraries unless it's run exactly where it was built. For example: bash@A: cd /var/tmp/SubProjects_3/main/dist/Debug/SunStudio-Solaris-Sparc bash@A: ./main ld.so.1: main: fatal: libhello3lib.so: open failed: No such file or directory Killed Relative -R's are fine for running under the IDE but a real deployed application has to be able to run "everywhere". There's a very good white paper that describes the best practices in this area: http://developers.sun.com/sunstudio/documentation/techart/stdlibdistr.html
Is it a bug in SubProject sample configuration? Should we fix it? I'm asking because no user complained about that.
No, it is not a bug in the SubProject sample. If they don't use relative paths, you cannot move the projects around and share them. So: - if you use relative paths, you cannot easily run them outside the IDE from a directory other than project top directory. - if you use absolute paths, you cannot easily move the projects around and share them. We use relative paths by default almost everywhere in the IDE. Users can easily use absolute paths if they want to so I don't think this is a big problem.
How does this "Users can easily use absolute paths" work exactly?
Thomas, I'm not quite buying the argument of "if we don't use relative paths we can't move stuff". Isn't it reasonable to expect that once a project has been moved that a rebuild is a prudent thing to do? Then one need not force absolute pathnames in project dependencies. They can always stay relative but the parameter to -R can be converted to an absolute pathname as the Makefile is regenerated. I also don't think it's entirely OK that the IDE generates an application that doesn't run successfully outside an IDE. That would reduce this IDE to producing toy applications that are never used by anyone except the developer, wouldn't it? I tried building a "package" (aka tarfile). I was going to argue that because of bad -R's you couldn't ship that tarfile to anyone. To my surprise I discovered that the tarfile doesn't even contain the .so's. So you still can't ship that tarfile to anyone and have it be useful, but for a _different_ reason. However, if the tarfile _did_ contain the .so's then relative -R's would make sense :-) but then they would have to be relative to some untarred installation not a project layout!
There was no activity on this issue for quite a long time. We apologize that the issue was not addressed so far due to lack of development resources. We might not have time in near future to fix this problem, so it is closed as WONTFIX. If the issue is still critical for you please do not hesitate to REOPEN it. Thank you for using our product and reporting bugs. We are really sorry that we were not able to fix this issue timely. Regards, CND team.