Issue 83548

Stefan - what are you smoking ? ;-)
linkoo is a critical developer tool of incredible usefulness - and it has been
working well for the last several years: and yes, it black-listed the 3-4
libraries it did not work for in the past & all was well.
I (for one) will not let it die, until something better replaces it (which
AFAICS it certainly has not).
Kendy - any chance you can unwind this breakage ? :-)

Sure - I'll try, I cannot live without it either.

Created attachment 49948 [details]
This seems to fix that.

The thing is that osl_getAbsoluteFileURL_impl_() is not the most cunning 
function under the sun - it seems to call realpath() on each and every piece 
of the path - apparently to be able to work even when the path does not exist.  
(I mean, to resolve /ugh/blah/haha.txt, it calls realpath() first on /ugh, 
then /ugh/blah, etc.)  A side effect of realpath() is that it resolves 
symlinks, which I'm not sure is wanted in each and every case.  So - from my 
point of view, I see several possible improvements here:

- osl_getAbsoluteFileURL_impl_() could first try to call realpath(), and if, 
and only if, the file/directory does not exist, do the manual removal of '.' 
and '..'.  It could even iterate from back to front so that the first 
non-failing realpath() would give us the path we want & the reason to end the 
iteration

- osl_getAbsoluteFileURL_impl_() would not expand 'basename' symlink, just the 
symlinks that are in the 'dirname' part - that's in fact what my patch does 
when OOO_ALLOW_LINKOO_SYMLINKS is exported.  I see no bad behavior with that 
so far - what risks are here, please?

Of course - if the above is not viable, let's please at least apply the patch 
with the OOO_ALLOW_LINKOO_SYMLINKS distinction.  Not being able to use linkoo 
is really painful.

@kendy:  I do not think it is a good idea to change the general
osl_getAbsoluteFileURL to work differently in different contexts---might open a
nice box of heisenbugs.  IMO better would be to get consensus to change
osl_getAbsoluteFileURL so that it *always* does not follow symlinks in the final
path segment (I put hro on cc).  What also has to be taken care of is how to
handle paths whose last segment is "." or "..".  (Apart from all that, if we
indeed need an environment variable, please start its name with "SAL_" instead
of "OOO_", following prior art.)

sb: OK, changed the name in ooo-build svn (will not attach the changed patch 
here).  http://wiki.services.openoffice.org/wiki/Environment_Variables did not 
give me impression that there's a rule, so thought that OOO_ is a good 
prefix - sorry :-(

hro: Please what do you think of the proposed changed not to follow symlinks 
in the final path segment?

Apparently I forgot to play the re-assign ping-pong ;-)

hro: Please, what do you think of the proposal not to follow symlinks in the 
final path segment?

Along with the SAL_... environment variable it's O.K. for me.

linkoo is not release relevant, change target to DevTools.

Changing the target to 3.0 because the change that is necessary touches OOo 
code.

sb: Seems that hro is OK with the environment variable...  As this variable 
will be set only for the developers using linkoo [and they should know what 
they are doing ;-)] - OK for you to proceed, please?  Or anything I can do to 
help to get this in?

@kendy:  I still consider my concerns from #desc6 valid.  But if anybody else
disagrees, so be it.

sb: Yes, I'd rather go without the variable as well, and change the behavior 
as proposed (*always* does not follow symlinks in the final path segment), but 
comment 9 did not help here.  From what I see, hro is OK with the variable, 
but says nothing about the proposal, so I'd go with the variable for now, and 
let the rest rot as a follow-up bug (something like 'SAL_ALLOW_LINKOO_SYMLINKS 
should go away') in IssueZilla.  That's the best I can do from my side, sorry.

*** Issue 86387 has been marked as a duplicate of this issue. ***

ping ! is target 3.0 still valid ?

Probably not.

seems not langer valid, closing

close issue.

I beg to differ.

@sb: any other avenue to make an installed office use solver/output tree libs
direcrly? if not, I'd definitely want this feature back.

@thb:  I thought kendy had made it work again as discussed in previous comments?

sb: So, the proposal to change the behavior of the 
osl_getAbsoluteFileURL_impl_() generally caused huge problems IIRC, namely on 
MacOSX, so the only thing was really to use the variable.

I am afraid I forgot to create a CWS for all this, let me fix that.  Sorry :-(

@kendy: ...not that I am personally keen to see any of those changes ;)

I'm adding this comment to all open issues with Issue Type == PATCH.  We have 220 such issues, many of them quite old.  I apologize for that.  

We need your help in prioritizing which patches should be integrated into our next release, Apache OpenOffice 4.0.

If you have submitted a patch and think it is applicable for AOO 4.0, please respond with a comment to let us know.

On the other hand, if the patch is no longer relevant, please let us know that as well.

If you have any general questions or want to discuss this further, please send a note to our dev mailing list:  dev@openoffice.apache.org

Thanks!

-Rob