Re: Building subversion runs svnversion, which fails

[Branko Čibej]

On 18.11.2019 16:14, Ryan Schmidt wrote:
> On Nov 18, 2019, at 08:44, Ryan Schmidt wrote:
>
>> The relevant part in the log is where it says:
>>
>> (subversion/svnversion/svnversion . 2> /dev/null ||  \
>>   svnversion . 2> /dev/null ||\
>>   echo "unknown"; \
>>  ) > 
>> /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_subversion/subversion/work/destroot/opt/local/include/subversion-1/svn-revision.txt
>> /bin/sh: line 1: 61814 Abort trap: 6   
>> subversion/svnversion/svnversion . 2> /dev/null
> And just to be clear, it should work if it were changed so that it ran:
>
> (DYLD_LIBRARY_PATH=where/the/built/libs/are subversion/svnversion/svnversion 
> . 2> /dev/null ||  \
>svnversion . 2> /dev/null ||\
>echo "unknown"; \
>   ) > 
> /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_subversion/subversion/work/destroot/opt/local/include/subversion-1/svn-revision.txt
>

As I wrote earlier, the real problem is that 'revision-install' runs
before 'local-install' has finished. The binaries have RPATH to the
install location embedded in them, so clearly the libraries haven't been
installed at the point where svnversion is run.

-- Brane

Re: Building subversion runs svnversion, which fails

[Ryan Schmidt]

On Nov 18, 2019, at 08:44, Ryan Schmidt wrote:

> The relevant part in the log is where it says:
> 
> (subversion/svnversion/svnversion . 2> /dev/null ||  \
>svnversion . 2> /dev/null ||\
>echo "unknown"; \
>   ) > 
> /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_subversion/subversion/work/destroot/opt/local/include/subversion-1/svn-revision.txt
> /bin/sh: line 1: 61814 Abort trap: 6   
> subversion/svnversion/svnversion . 2> /dev/null

And just to be clear, it should work if it were changed so that it ran:

(DYLD_LIBRARY_PATH=where/the/built/libs/are subversion/svnversion/svnversion . 
2> /dev/null ||  \
 svnversion . 2> /dev/null ||\
 echo "unknown"; \
) > 
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_subversion/subversion/work/destroot/opt/local/include/subversion-1/svn-revision.txt

Re: Building subversion runs svnversion, which fails

[Ryan Schmidt]

On Nov 17, 2019, at 15:24, Nathan Hartman wrote:

> On Sun, Nov 17, 2019 at 2:47 PM Ryan Schmidt wrote:
> 
> > Hi, I noticed this bug in subversion on macOS. I reported it here:
> > 
> > https://trac.macports.org/ticket/59712
> > 
> > But it's really an upstream issue so I would like to report it here
> > as well.
> > 
> > The subversion build evidently runs the just-built svnversion at
> > some point. This crashes, because the libraries it's linked with
> > haven't been installed yet, and I guess it's not setting
> > DYLD_LIBRARY_PATH to the path where the built libraries are. I
> > assume that the fix will be setting that variable.
> 
> I am not an expert on this subject but IIRC setting DYLD_LIBRARY_PATH
> will *not* help because of something called SIP (System Integrity
> Protection) on macOS.

On newer versions of macOS, DYLD_* environment variables are no longer passed 
down to subshells. This merely means that you need to set DYLD_LIBRARY_PATH at 
the right time, in other words right as you're running svnversion, and not in 
some top-level script that will eventually after calling various sub scripts 
run svnversion.


> But I wonder, why does this fail? Subversion's test suite (which runs
> the svn binaries) runs just fine. It stands to reason that svnversion
> should run just fine, too.

I have not looked at your build system, but it fails for the reason I stated.


> That tells me that it must be running, not crashing.

It is crashing. The operating system crash logs (attached to the MacPorts 
ticket) were what alerted me to the problem.


> Of course, I could be mistaken. Please could you show us more output
> from 'make install' than the 3 lines in the MacPorts Trac issue?

Sure, here's one of the logs from our build system:

https://build.macports.org/builders/ports-10.14_x86_64-builder/builds/44459/steps/install-port/logs/stdio

The relevant part in the log is where it says:

(subversion/svnversion/svnversion . 2> /dev/null ||  \
 svnversion . 2> /dev/null ||\
 echo "unknown"; \
) > 
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_devel_subversion/subversion/work/destroot/opt/local/include/subversion-1/svn-revision.txt
/bin/sh: line 1: 61814 Abort trap: 6   subversion/svnversion/svnversion 
. 2> /dev/null


> Also, are you building from a distribution tarball or from a working
> copy checked out from Subversion's source repository?

Distribution tarball.

Re: Building subversion runs svnversion, which fails

[Branko Čibej]

On 17.11.2019 22:24, Nathan Hartman wrote:
> On Sun, Nov 17, 2019 at 2:47 PM Ryan Schmidt  2...@ryandesign.com > wrote:
> > Hi, I noticed this bug in subversion on macOS. I reported it here:
> > 
> > https://trac.macports.org/ticket/59712
> > 
> > But it's really an upstream issue so I would like to report it here
> > as well.
> > 
> > The subversion build evidently runs the just-built svnversion at
> > some point. This crashes, because the libraries it's linked with
> > haven't been installed yet, and I guess it's not setting
> > DYLD_LIBRARY_PATH to the path where the built libraries are. I
> > assume that the fix will be setting that variable.
>
> I am not an expert on this subject but IIRC setting DYLD_LIBRARY_PATH
> will *not* help because of something called SIP (System Integrity
> Protection) on macOS.


SIP only affects how DYLD_LIBRARY_PATH works for system binaries, not
stuff you build yourself. For example, our test suite runs just fine in
the build directory with DYLD_LIBRARY_PATH set, but the Python (2)
bindings test suite does not, because it's run by the system Python binary.


Anyway: the short-term solution would be to run 'make install' with
'-j1' so that local-install runs before revision-install. The long-term
solution is to either remove that useless stanza from the Makefile, or
add proper dependencies between those two targets.

-- Brane

Re: Building subversion runs svnversion, which fails

[Nathan Hartman]

On Sun, Nov 17, 2019 at 4:24 PM Nathan Hartman 
wrote:

> On Sun, Nov 17, 2019 at 2:47 PM Ryan Schmidt  2...@ryandesign.com> wrote:
> > The MacPorts maintainer of subversion suggested:
> >
> >> That's almost certainly from the revision-install target in the
> >> top level makefile. If it ran, it would populate
> >> ${prefix}/include/subversion-1/svn-revision.txt with "Unversioned
> >> directory", since it crashes that file gets populated with
> >> "unknown". I don't think it actually matters.
>
> Wait a minute.
>
> "Unversioned directory" is one of the possible outputs of svnversion.
>

(snip)

That tells me that it must be running, not crashing.
>
> Of course, I could be mistaken.
>

I was mistaken.

You wrote that the file contains "unknown" not "Unversioned directory"; I
misread that earlier. In this case, yes, it is crashing. The "unknown" is
produced by the makefile if all else fails. The OR logic is also the reason
why 'make' doesn't quit at this point.

I am not at my computer right now so I cannot test why this is failing. It
might have something to do with order of operations. I'll investigate
further...

Thanks for your report...

Nathan

Re: Building subversion runs svnversion, which fails

[Nathan Hartman]

On Sun, Nov 17, 2019 at 2:47 PM Ryan Schmidt  wrote:
> Hi, I noticed this bug in subversion on macOS. I reported it here:
>
> https://trac.macports.org/ticket/59712
>
> But it's really an upstream issue so I would like to report it here
> as well.
>
> The subversion build evidently runs the just-built svnversion at
> some point. This crashes, because the libraries it's linked with
> haven't been installed yet, and I guess it's not setting
> DYLD_LIBRARY_PATH to the path where the built libraries are. I
> assume that the fix will be setting that variable.

I am not an expert on this subject but IIRC setting DYLD_LIBRARY_PATH
will *not* help because of something called SIP (System Integrity
Protection) on macOS.

But I wonder, why does this fail? Subversion's test suite (which runs
the svn binaries) runs just fine. It stands to reason that svnversion
should run just fine, too.

> The MacPorts maintainer of subversion suggested:
>
>> That's almost certainly from the revision-install target in the
>> top level makefile. If it ran, it would populate
>> ${prefix}/include/subversion-1/svn-revision.txt with "Unversioned
>> directory", since it crashes that file gets populated with
>> "unknown". I don't think it actually matters.

Wait a minute.

"Unversioned directory" is one of the possible outputs of svnversion.

$ svnversion --help
usage: svnversion [OPTIONS] [WC_PATH [TRAIL_URL]]
Subversion working copy identification tool.
(snip)
  If WC_PATH is an unversioned path, the program will output
  'Unversioned directory' or 'Unversioned file'.  If WC_PATH is
  an added or copied or moved path, the program will output
  'Uncommitted local addition, copy or move'.

That tells me that it must be running, not crashing.

Of course, I could be mistaken. Please could you show us more output
from 'make install' than the 3 lines in the MacPorts Trac issue?

Also, are you building from a distribution tarball or from a working
copy checked out from Subversion's source repository?

Thanks,
Nathan

Building subversion runs svnversion, which fails

[Ryan Schmidt]

Hi, I noticed this bug in subversion on macOS. I reported it here:

https://trac.macports.org/ticket/59712

But it's really an upstream issue so I would like to report it here as well.

The subversion build evidently runs the just-built svnversion at some point. 
This crashes, because the libraries it's linked with haven't been installed 
yet, and I guess it's not setting DYLD_LIBRARY_PATH to the path where the built 
libraries are. I assume that the fix will be setting that variable.

This does not cause the build of subversion to fail, but whatever it's running 
svnversion for can't be getting the correct result. Whether that's important, I 
don't know.

The MacPorts maintainer of subversion suggested:

> That's almost certainly from the revision-install target in the top level 
> makefile. If it ran, it would populate 
> ${prefix}/include/subversion-1/svn-revision.txt with "Unversioned directory", 
> since it crashes that file gets populated with "unknown". I don't think it 
> actually matters.

Nevertheless, fixing the build so that it does not run a program that crashes 
would be good.