Hi Robert, > -----Ursprüngliche Nachricht----- > Von: Robert Schwebel <[EMAIL PROTECTED]> > Gesendet: 07.02.07 22:47:05 > An: [email protected] > Betreff: [DotGNU] Build System Changes
> Hi, > > Just some short notes about today's irc. I'm currently offline during > the day because of workshop for a customer, so offline communication is > better than irc atm :-) > > > [08:49:05]<klausT|work> replacing ranlib with libtool in pnet somehow > > didn't work on my box > > What happened? libtool complained about file not found. I haven't looked at this further because i wanted first to get a working version on my boxes. We can look at this issue later. > > > [09:01:36]<Brubbel> running autoheader, automake, autoconf > > We should re-add the AM_MAINTAINER_MODE. In the meantime I've found out that, > if you have it in, you can enable the auto-generation of the generated files > (that's what you want as a maintainer) by adding --enable-maintainer-mode; > whereas normal users aren't bothered by magically starting autotools (users > are > not supposed to have autotools installed). > Ok. I'll re-add the AM_MAINTAINER_MODE to the configure.in of treecc. > > [09:02:38]<Brubbel> what does make distcheck do? > > It runs "make dist", which packages the tarball according to the project > rules. It then extracts the packaged tarball to "pnet-<version>", > creates a _build/ directory in that dir and makes all sources + dirs of > the source tree read-only. Then it makes an out-of-tree build in > _build/, runs the testsuite and, if everything went right, makes > distclean and checks of some files are left in the build dir, which > would mean that the clean rules are incorrect. If everything went right, > you have a tarball (tar.gz or tar.bz2) which is ready for release. > > Short - it does what you want to do if you want to make a release :-) > > > [09:03:18]<Brubbel> ditcheck error: treecc is required to build and > > can be obtained from ... > > treecc has to be in your path. If you don't have it there regularly, > please just run "PATH=/path/to/treenet:$PATH ./configure ...". > > > [09:04:07]<Brubbel> where is the tarball stored ? > > Directly in the toplevel directory, where you started configure. > > > [09:05:44]<Brubbel> I'M configuring with --prefix=xxx > > --prefix specifies the path in your "target directory". Note that this > isn't necessarily identical with where it is really installed; for > example, you may want to have the stuff installed on your embedded > system in the user hierarchy, so you would --prefix=/usr. Nevertheless, > if you have for example your nfsroot dir for the devel board in > $HOME/root/, you would run 'make install DESTDIR=$HOME/root' and it > would magically install into that dir. Nevertheless, if some of the > project files had paths compiled in, they would corectly refer to the / > as seen by embedded system, not by the host. > > > [09:06:46]<klausT|work> treecc is required to be somewhere in the $PATH > > [09:07:05]<Brubbel> uuu that's bad > > It wasn't different before the changes. > > > [09:09:41]<Brubbel> configure: error: C compiler cannot create executables > > [09:10:13]<Brubbel> error: ../../libffi/configure failed for libffi > The strange thing here was an added -m64 to the call of gcc. I dunno where that comes from. > That's pretty strange. Did you find out why? If not, please send me your > config.log. I'll retest with today's CVS. > > > [09:31:05]<Brubbel> configure: error: ../../libffi/configure failed for > > libffi > > ../.. looks strange. Why does something try to use that path here? > > Robert > -- Klaus _______________________________________________________________________ Viren-Scan für Ihren PC! Jetzt für jeden. Sofort, online und kostenlos. Gleich testen! http://www.pc-sicherheit.web.de/freescan/?mc=022222 _______________________________________________ Developers mailing list [email protected] http://dotgnu.org/mailman/listinfo/developers
