Bug 10874 - mono tarball fails to compile since 3.0.3 (if using ./autogen.sh instead of ./configure): No rule to make target `../mini/libmono-2.0.la', needed by `monodis'
Summary: mono tarball fails to compile since 3.0.3 (if using ./autogen.sh instead of ....
Alias: None
Product: Runtime
Classification: Mono
Component: Tools ()
Version: unspecified
Hardware: PC Linux
: --- normal
Target Milestone: ---
Assignee: Bugzilla
Depends on:
Reported: 2013-03-04 07:55 UTC by Andres G. Aragoneses
Modified: 2013-03-08 11:53 UTC (History)
4 users (show)

Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.

Please create a new report on GitHub or Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:

Description Andres G. Aragoneses 2013-03-04 07:55:48 UTC
If you download 3.0.6 tarball in a debian squeeze box, and try to compile, you get:

make[3]: Leaving directory `/home/lockerteam/mono-3.0.6/mono/io-layer'
Making all in cil
make[3]: Entering directory `/home/lockerteam/mono-3.0.6/mono/cil'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/lockerteam/mono-3.0.6/mono/cil'
Making all in metadata
make[3]: Entering directory `/home/lockerteam/mono-3.0.6/mono/metadata'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/lockerteam/mono-3.0.6/mono/metadata'
Making all in mini
make[3]: Entering directory `/home/lockerteam/mono-3.0.6/mono/mini'
make[3]: Nothing to be done for `all'.
make[3]: Leaving directory `/home/lockerteam/mono-3.0.6/mono/mini'
Making all in dis
make[3]: Entering directory `/home/lockerteam/mono-3.0.6/mono/dis'
  CC     get.o
  CC     dis-cil.o
  CC     util.o
  AR     libmonodis.a
  CC     dump.o
  CC     main.o
  CC     declsec.o
make[3]: *** No rule to make target `../mini/libmono-2.0.la', needed by `monodis'.  Stop.
make[3]: Leaving directory `/home/lockerteam/mono-3.0.6/mono/dis'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/home/lockerteam/mono-3.0.6/mono'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/lockerteam/mono-3.0.6'
make: *** [all] Error 2
Comment 1 Andres G. Aragoneses 2013-03-04 13:35:47 UTC
This is a regression that appears for the first time in the mono 3.0.3 tarball, the mono 3.0.2 tarball works fine.
Comment 2 Andres G. Aragoneses 2013-03-04 14:10:42 UTC
This change happened between these 2 releases, which I think is very related:

Comment 3 Andres G. Aragoneses 2013-03-04 14:39:32 UTC
So it turns out this doesn't happen when using ./configure instead of ./autogen.sh. Should the tarballs just not include autogen.sh?
Comment 4 Zoltan Varga 2013-03-04 14:46:33 UTC
Should be fixed.
Comment 5 Andres G. Aragoneses 2013-03-04 14:48:23 UTC
https://github.com/mono/mono/commit/1cd10c9d51420b06608c08be47cf349adff10d58 looks right! Thanks Zoltan, will test with 3.0.7 tarball when it's out.
Comment 6 Hin-Tak Leung 2013-03-08 08:06:48 UTC
Argh, you committed a fix around the same time I looked into it and found a work-around. Here is the proof-of-concept patch:

--- mono-3.0.3/autogen.sh~	2013-01-08 18:41:10.000000000 +0000
+++ mono-3.0.3/autogen.sh	2013-03-03 06:43:51.283308046 +0000
@@ -117,9 +117,6 @@
 	pushd ../mono-extensions/scripts
 	sh ./prepare-repo.sh || exit 1
-	cat mono/mini/Makefile.am.in > mono/mini/Makefile.am
-	cat mono/metadata/Makefile.am.in > mono/metadata/Makefile.am

Those two cat's were introduced between 3.0.2 and 3.0.3 . I thought of two ways of fixing it: (1) test for the existence of mono/mini/Makefile.am.in and mono/metadata/Makefile.am.in instead of blindly cat'ing non-existent files (and thus truncating the two destinations, which is why the issue reported there happened), (2) ships the two am.in in the release tar ball.

It seems that you have done (2). For those who like to build 3.0.3 - 3.0.6 from tar balls, (before 3.0.7 is released), the above patch can be used.

A solution in the direction of (1) might be (untested) modifying the above to do:

if [ -f mono/mini/Makefile.am.in ]; then
   cat mono/mini/Makefile.am.in > mono/mini/Makefile.am
Comment 7 Andres G. Aragoneses 2013-03-08 11:36:50 UTC
Hin-Tak thanks for that info, but there's an easier work-around (see the title of the bug: call configure instead of autogen.sh)
Comment 8 Hin-Tak Leung 2013-03-08 11:53:33 UTC
I came across this problem when I was trying to adapt fedora's spec file for older mono to build newer versions. It runs autogen.sh, patches some of the generated files, then runs autoreconf again . I assume that it was done that way for a reason. (probably for multi-arch builds).

In fact the bundled cross-compile script,  build-mingw32.sh, also invokes autogen.sh . That would haven also been broken on release tar balls from 3.0.3 onwards.