2017-11-26 8:21 GMT+09:00 Ilya Mikhaltsou <[email protected]>:

> > That's the case of recent macOS versions.
> >
> >
> > Judging from the code, 10.3 returns libruby.a as $librubyarg while it
> doesn't have such a static library, but does have a shared library.  As a
> result,  RUBY_LIBS is set to something like "libruby.a -L/.../" which
> causes link error.  Therefore, libruby.a must be replaced with -lruby if
> $librubydir/libruby.a doesn't exist and if $librubyarg is equal to libruby.a
> >
>
> I couldn’t find any reference neither to this nor to such problem with
> LIBRUBYARG in RbConfig on OS X 10.3. Can you please substantiate this by
> some links to discussions?
>

Read the code of the current version of configure.ac.


> > The correct variable is $librubya.
> >
> >
> > No.  Our goal is to set RUBY_LIBS to canonical "-L$rubylibdir
> $librubyarg", which would look like, e.g., "-L/usr/local/lib -lruby".  Only
> for 10.3 (or systems having the same RbConfig bug), $librubyarg must be
> replaced with -lruby to avoid link error.  We don't need to care about
> libruby-X.Y..Z-static.a at all from the outset.
> >
>
> Our goal is never that, since vim attempts to use static library on other
> unixes. The specific case for macOS is exactly due to inexistence of a
> static library there.
>

No.  If vim were to make any attempt to link against a static library just
like you claim, the code would be

if test -f "$rubylibdir/$librubya"; then
 librubyarg="$librubya"

instead of the current

if test -f "$rubylibdir/$librubya"; then
 librubyarg="$librubyarg"

Currently, if $rubylibdir/$librubya exists, then it uses $librubyarg
instead of $librubya.  Basically, $librubyarg is '-lruby'.  However, as the
code indicates, there's a case where $librubyarg is set to libruby.a.
Only for that case, libruby.a is chosen (This is OK since it turns out to
exist).   Otherwise, -lruby is chosen even if libruby.a exists.



>
> What we need to care are two things: (1) the in-existence of the static
> library and (2) the sanity of the ruby configuration. When both are met, we
> decide that there simply is no static library at all.
>

Too abstract for me to understand.


> >
> > Besides that, as I already wrote above, your current patch makes the
> code about macOS completely useless. And I’m trying to ask you what is the
> point of it.
> >
> >
> >
> > You argued on the basis of a wrong assumption (See above). Rather, your
> patch breaks 10.3 build.
> >
>
> Unfortunately, I don’t have OS X 10.3. I would wonder if this is truly the
> only thing that breaks it and if the current version even builds there. As
> well, as I would wonder if there is anyone left wishing to build latest vim
> on OS X 10.3.
>

Note that the question was made last May:
https://stackoverflow.com/questions/43956208/does-mac-os-x-have-the-dev-ptmx-file
, and that Patch 8.0.1166 was merged last September.  You can't drop the
support for old Mac OS X's in favor of your patch.


> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups
> "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> For more options, visit https://groups.google.com/d/optout.
>

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
For more options, visit https://groups.google.com/d/optout.

Raspunde prin e-mail lui