Re: Cross builds and upgrade path from 4.x are broken in usr.bin/file
On Fri, 17 Aug 2001, David O'Brien wrote:
> On Wed, Aug 15, 2001 at 12:40:19PM +1000, Bruce Evans wrote:
> > On Tue, 14 Aug 2001, Ruslan Ermilov wrote:
> >
> > > On Tue, Aug 14, 2001 at 08:55:56AM -0700, David O'Brien wrote:
> > > > >From a correctness stand point, building the .mgc files at install time
> > > > is the correct thing to do... or maybe we should do both -- doing the
> > > > [re]creation of the .mgc files at install time in the cross-[arch-]build
> > > > case.
> >
> > Not both.
>
> Which do you prefer? The CC_HOST way, the build-tools way, or the at
> install time way?
build-tools.
> > > +build-tools: mkmagic
> > > +
> > > +mkmagic: apprentice.c print-hacked.c
> > > + ${CC} -DHAVE_CONFIG_H -DCOMPILE_ONLY \
> > > + -I${.CURDIR} -I${SRCDIR} -o ${.TARGET} ${.ALLSRC}
> >
> > This should use CFLAGS if possible, and should use LDFLAGS, something
> > like:
> >
> > ${CC} -DCOMPILE_ONLY {CFLAGS} ${LDFLAGS} -o ${.TARGET} ${.ALLSRC}
>
> The include path in CFLAGS is wrong for this:
>
> -I/FBSD/5.x/usr.bin/file -I/FBSD/5.x/usr.bin/file/../../contrib/file
> -I/usr/obj/FBSD/5.x/i386/usr/include
>
> namely pointing into /usr/obj.
The extra directory seems to be a bug elsewhere. bsd.lib.mk and
bsd.prog.mk add -I${DESTDIR}/usr/include to CFLAGS if DESTDIR is set.
This is the wrong place to add it, but /usr/src/Makefile.inc1 relies
on this for the WMAKEENV (world) stage. Makefile.inc1 also sets DESTDIR
for the BMAKEENV (bootstrap-tool) and XMAKEENV (cross-tools) stages.
I think this breaks these stages if NOCLEAN is set (if NOCLEAN is not
set, then the extra include dir is cleaned early, and it remains
unpopulated until the WMAKEENV stage). I think this is not broken for
the TMAKEENV (build-tools) stage unless DESTDIR is set externally
(and NOCLEAN is set). You saw the extra include dir for the `file'
build-tool because you set DESTDIR externally.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Cross builds and upgrade path from 4.x are broken in usr.bin/file
In message <[EMAIL PROTECTED]> "David O'Brien" writes: : We should decide if a cross-platform must be : installworld'able on the host, target, or both. Having brought up ports on other OSes, I've found the ability to install a target on a host to be useful. I think it should be a goal, unless it is really hard to do. However, if one of the two needs to be broken, doing the install on the target is more imporant. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Cross builds and upgrade path from 4.x are broken in usr.bin/file
On Fri, Aug 17, 2001 at 08:49:10AM -0700, David O'Brien wrote:
> On Fri, Aug 10, 2001 at 05:37:51PM +0300, Ruslan Ermilov wrote:
> > I can't believe I hear that from you, Bruce. :-)
> > Generation at install time is a damn bad idea, please see below.
> [...]
> > 1. This won't work for cross-platform installworld, since ./file
> > is targetted for a different platform. (My version builds the
> > xfile build-tool for the build platform and compiles .mgc files
> > in ${.OBJDIR}.)
>
> You are generalizing. It breaks cross-platform installworld when done on
> the build host. It does not break cross-platform installworlds when done
> on the target host. We should decide if a cross-platform must be
> installworld'able on the host, target, or both.
>
If we build at build time only, we always build on build host.
And that will work in both cases of cross-platform installworld,
as it won't build anything during install time.
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Cross builds and upgrade path from 4.x are broken in usr.bin/file
On Fri, Aug 10, 2001 at 05:37:51PM +0300, Ruslan Ermilov wrote:
> I can't believe I hear that from you, Bruce. :-)
> Generation at install time is a damn bad idea, please see below.
[...]
> 1. This won't work for cross-platform installworld, since ./file
> is targetted for a different platform. (My version builds the
> xfile build-tool for the build platform and compiles .mgc files
> in ${.OBJDIR}.)
You are generalizing. It breaks cross-platform installworld when done on
the build host. It does not break cross-platform installworlds when done
on the target host. We should decide if a cross-platform must be
installworld'able on the host, target, or both.
--
-- David ([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Cross builds and upgrade path from 4.x are broken in usr.bin/file
On Wed, Aug 15, 2001 at 12:40:19PM +1000, Bruce Evans wrote:
> On Tue, 14 Aug 2001, Ruslan Ermilov wrote:
>
> > On Tue, Aug 14, 2001 at 08:55:56AM -0700, David O'Brien wrote:
> > > >From a correctness stand point, building the .mgc files at install time
> > > is the correct thing to do... or maybe we should do both -- doing the
> > > [re]creation of the .mgc files at install time in the cross-[arch-]build
> > > case.
>
> Not both.
Which do you prefer? The CC_HOST way, the build-tools way, or the at
install time way?
> > +build-tools: mkmagic
> > +
> > +mkmagic: apprentice.c print-hacked.c
> > + ${CC} -DHAVE_CONFIG_H -DCOMPILE_ONLY \
> > + -I${.CURDIR} -I${SRCDIR} -o ${.TARGET} ${.ALLSRC}
>
> This should use CFLAGS if possible, and should use LDFLAGS, something
> like:
>
> ${CC} -DCOMPILE_ONLY {CFLAGS} ${LDFLAGS} -o ${.TARGET} ${.ALLSRC}
The include path in CFLAGS is wrong for this:
-I/FBSD/5.x/usr.bin/file -I/FBSD/5.x/usr.bin/file/../../contrib/file
-I/usr/obj/FBSD/5.x/i386/usr/include
namely pointing into /usr/obj.
--
-- David ([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Cross builds and upgrade path from 4.x are broken in usr.bin/file
On Wed, 15 Aug 2001, Ruslan Ermilov wrote:
> On Wed, Aug 15, 2001 at 12:40:19PM +1000, Bruce Evans wrote:
> > I agree (except the build-tools concept is a hack to work around
> > build-tools binaries not being buildable and installable in the usual
> > way (with 1 binary per Makefile)).
> >
> It seems pretty easy to add src/tools/build-tools/, and move all the
> build-tools there. What do you say?
Ugh :-). You would also need messes like src/tools/build-tools/gnu (or
is it src/gnu/tools/build-tools? :-) for cc/cc_tools. Then when plain
"make all" is run in in a program directory, it would have to reach out
to build tools in far-flung source and/or object directories.
I was thinking of just having file/tools and sh/tools, etc. Note that
there is already cc/cc_tools, but it doesn't completely solve the cross-
building problems. Some infrastructure is missing (a place to install
the tools and a way to skip tools directories only when cross-building),
and there are some complications with source files built using the tools
(these should not be built in the same object directory as the tools).
> [...]
> > See sh/Makefile for other tweaks (depend on .o instead of .c ...). Other
> > probems with this (generally shared with all build-tools binaries):
> > - CFLAGS for the main binary may be inappropriate for the tools
> > - missing dependencies on headers.
> >
> Dependency of a build-tool on .o instead of .c is bad if:
>
> 1) build-tools are built in the same ${.OBJDIR} as the main ${PROG}
> (this is always true)
> 2) objects for a build-tool are created for the host arch
> 3) objects for a ${PROG} are created for a different arch
> 4) ${PROG} and build-tool share one or more object files
>
> This is not the case for bin/sh, but it's true for usr.bin/file.
Only (4) is crucial. It can be worked around by renaming some
object files.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Cross builds and upgrade path from 4.x are broken in usr.bin/file
On Wed, Aug 15, 2001 at 12:40:19PM +1000, Bruce Evans wrote:
[...]
> > > +mkmagic: apprentice.c print-hacked.c
> > > + ${HOST_CC} -o mkmagic -DHAVE_CONFIG_H -DCOMPILE_ONLY \
> > > + -I${.CURDIR} -I${SRCDIR} ${.ALLSRC}
> > >
> > Whoa, cool!
> >
> > That's what I wanted from the very beginning (-DCOMPILE_ONLY knob).
> > It then fits just nicely into the `build-tools' concept. And we
> > don't need this ugly HOST_CC hack for Makefile.inc1, as ${CC} is
> > set correctly during the `build-tools' stage. Let's don't reinvent
> > the wheel, and please try the attached patch instead.
>
> I agree (except the build-tools concept is a hack to work around
> build-tools binaries not being buildable and installable in the usual
> way (with 1 binary per Makefile)).
>
It seems pretty easy to add src/tools/build-tools/, and move all the
build-tools there. What do you say?
[...]
> See sh/Makefile for other tweaks (depend on .o instead of .c ...). Other
> probems with this (generally shared with all build-tools binaries):
> - CFLAGS for the main binary may be inappropriate for the tools
> - missing dependencies on headers.
>
Dependency of a build-tool on .o instead of .c is bad if:
1) build-tools are built in the same ${.OBJDIR} as the main ${PROG}
(this is always true)
2) objects for a build-tool are created for the host arch
3) objects for a ${PROG} are created for a different arch
4) ${PROG} and build-tool share one or more object files
This is not the case for bin/sh, but it's true for usr.bin/file.
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Cross builds and upgrade path from 4.x are broken in usr.bin/file
On Tue, 14 Aug 2001, David O'Brien wrote:
> On Tue, Aug 14, 2001 at 08:30:45PM +0300, Ruslan Ermilov wrote:
>
> > The build in ${DESTDIR} is allowed, we, for
> > example, execute makewhatis(1) at the end of `installworld'. But this
> > "build" is implicit, i.e., it's not done by make dependencies.
>
> What is wrong with doing the .mgc creation during make install?
1. May have cross building problems. Installing on the host should work
someday.
2. Doesn't work as well as install(1) unless we add most of install(1)'s
features to the creation program.
> The
> behavior of ``file -C'' is to write the .mgc in the same directory as the
> source file. That behavior does not make me happy, and is the source of
> the use of "magic.mime.PITA".
It takes 23 lines just to append ".mgc" to the source file name. This
misfeature could be left out for the COMPILE_ONLY case.
> > That's what I wanted from the very beginning (-DCOMPILE_ONLY knob).
> > It then fits just nicely into the `build-tools' concept. And we
> > don't need this ugly HOST_CC hack for Makefile.inc1, as ${CC} is
> > set correctly during the `build-tools' stage.
>
> I personally often find `build-tools' a hack, and would really prefer to
> build things that can be at program compile time.
The correct way is to build the tools earlier, in one directory for each
tool so that the standard rules work right and different compilation
environments can easily be arranged. This would be easy to implement
for file(1) since there is only one tool.
> > Let's don't reinvent the wheel, and please try the attached patch
> > instead.
>
> I don't see why HOST_CC is such a hack. I think it is more clear what is
> going on than adding mkmagic to build-tools.
It essentially hard-codes a special case of TMAKE/TMAKEENV. It is
superficially easier to understand, but actually much more complicated.
TMAKEENV gives a relatively simple host environment, with things like
COMPILER_PATH unset. When you build mkmagic later, the more complicated
WMAKEENV environment is in effect, and you need to kill parts of it
to get back to TMAKEENV. This is not easy. HOST_CC only sets a couple
of parts IIRC, and doesn't do this quite right (it should unset
COMPILER_PATH instead of setting it ...).
> > RCS file: /home/ncvs/src/usr.bin/file/Makefile,v
> ...
> > +build-tools: mkmagic
> > +
> > +mkmagic: apprentice.c print-hacked.c
> > + ${CC} -DHAVE_CONFIG_H -DCOMPILE_ONLY \
> > + -I${.CURDIR} -I${SRCDIR} -o ${.TARGET} ${.ALLSRC}
>
> Why shouldn't mkmagic be added to CLEANFILES?
It is (just in a different place?).
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Cross builds and upgrade path from 4.x are broken in usr.bin/file
On Tue, 14 Aug 2001, Ruslan Ermilov wrote:
> On Tue, Aug 14, 2001 at 08:55:56AM -0700, David O'Brien wrote:
> > >From a correctness stand point, building the .mgc files at install time
> > is the correct thing to do... or maybe we should do both -- doing the
> > [re]creation of the .mgc files at install time in the cross-[arch-]build
> > case.
Not both.
> > +mkmagic: apprentice.c print-hacked.c
> > + ${HOST_CC} -o mkmagic -DHAVE_CONFIG_H -DCOMPILE_ONLY \
> > + -I${.CURDIR} -I${SRCDIR} ${.ALLSRC}
> >
> Whoa, cool!
>
> That's what I wanted from the very beginning (-DCOMPILE_ONLY knob).
> It then fits just nicely into the `build-tools' concept. And we
> don't need this ugly HOST_CC hack for Makefile.inc1, as ${CC} is
> set correctly during the `build-tools' stage. Let's don't reinvent
> the wheel, and please try the attached patch instead.
I agree (except the build-tools concept is a hack to work around
build-tools binaries not being buildable and installable in the usual
way (with 1 binary per Makefile)).
> Index: usr.bin/file/Makefile
> ===
> RCS file: /home/ncvs/src/usr.bin/file/Makefile,v
> retrieving revision 1.21
> diff -u -r1.21 Makefile
> --- usr.bin/file/Makefile 2001/08/08 16:19:30 1.21
> +++ usr.bin/file/Makefile 2001/08/14 17:30:11
> @@ -34,23 +34,29 @@
> CFLAGS+= -DMAGIC='"${MAGICPATH}/magic"' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H
> CFLAGS+= -I${.CURDIR} -I${SRCDIR}
>
> -CLEANFILES+= magic magic.mgc magic.mime.mgc magic.mime.PITA
> +CLEANFILES+= mkmagic magic magic.mgc magic.mime.mgc magic.mime.PITA
CLEANFILES= magic magic.mgc magic.mime.mgc magic.mime.PITA mkmagic
(This fixes disorder and the usual style bug for the initial assignment
to CLEANFILES.)
>
> MAGFILES=${SRCDIR}/Header\
> ${SRCDIR}/Localstuff\
> ${SRCDIR}/Magdir/[a-z]*
>
> -all: file magic magic.mgc magic.mime.mgc
> +all: ${PROG} magic magic.mgc magic.mime.mgc
all: magic magic.mgc magic.mime.mgc
(Don't depend on `file' twice. Putting it first may have been a workaround
for broken dependencies in an old version of the Makefile.)
> +build-tools: mkmagic
> +
> +mkmagic: apprentice.c print-hacked.c
> + ${CC} -DHAVE_CONFIG_H -DCOMPILE_ONLY \
> + -I${.CURDIR} -I${SRCDIR} -o ${.TARGET} ${.ALLSRC}
This should use CFLAGS if possible, and should use LDFLAGS, something
like:
${CC} -DCOMPILE_ONLY {CFLAGS} ${LDFLAGS} -o ${.TARGET} ${.ALLSRC}
See sh/Makefile for other tweaks (depend on .o instead of .c ...). Other
probems with this (generally shared with all build-tools binaries):
- CFLAGS for the main binary may be inappropriate for the tools
- missing dependencies on headers.
> +
> magic: ${MAGFILES}
> cat ${.ALLSRC} > ${.TARGET}
>
> -magic.mgc: file magic
> - ./${PROG} -C -m magic
> +magic.mgc: mkmagic magic
> + ./mkmagic magic
>
> -magic.mime.mgc: file magic.mime
> +magic.mime.mgc: mkmagic magic.mime
> ln -sf ${SRCDIR}/magic.mime magic.mime.PITA
> - ./${PROG} -C -m magic.mime.PITA
> + ./mkmagic magic.mime.PITA
> mv magic.mime.PITA.mgc magic.mime.mgc
>
> CLEANFILES+= print-hacked.c
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Cross builds and upgrade path from 4.x are broken in usr.bin/file
On Tue, Aug 14, 2001 at 08:30:45PM +0300, Ruslan Ermilov wrote:
> Just to clarify. Nothing should be built in ${.OBJDIR} at install time,
> as it may be read-only.
Correct.
> The build in ${DESTDIR} is allowed, we, for
> example, execute makewhatis(1) at the end of `installworld'. But this
> "build" is implicit, i.e., it's not done by make dependencies.
What is wrong with doing the .mgc creation during make install? The
behavior of ``file -C'' is to write the .mgc in the same directory as the
source file. That behavior does not make me happy, and is the source of
the use of "magic.mime.PITA".
> And
> also note that only bootstrap-tools and utilities copied to the
> ${TMPPATH} as the first step of `installworld' are allowed during
> `installworld'.
>
> > +mkmagic: apprentice.c print-hacked.c
> > + ${HOST_CC} -o mkmagic -DHAVE_CONFIG_H -DCOMPILE_ONLY \
> > + -I${.CURDIR} -I${SRCDIR} ${.ALLSRC}
> >
> Whoa, cool!
>
> That's what I wanted from the very beginning (-DCOMPILE_ONLY knob).
> It then fits just nicely into the `build-tools' concept. And we
> don't need this ugly HOST_CC hack for Makefile.inc1, as ${CC} is
> set correctly during the `build-tools' stage.
I personally often find `build-tools' a hack, and would really prefer to
build things that can be at program compile time.
> Let's don't reinvent the wheel, and please try the attached patch
> instead.
I don't see why HOST_CC is such a hack. I think it is more clear what is
going on than adding mkmagic to build-tools.
> RCS file: /home/ncvs/src/usr.bin/file/Makefile,v
...
> +build-tools: mkmagic
> +
> +mkmagic: apprentice.c print-hacked.c
> + ${CC} -DHAVE_CONFIG_H -DCOMPILE_ONLY \
> + -I${.CURDIR} -I${SRCDIR} -o ${.TARGET} ${.ALLSRC}
Why shouldn't mkmagic be added to CLEANFILES?
--
-- David ([EMAIL PROTECTED])
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Cross builds and upgrade path from 4.x are broken in usr.bin/file
On Tue, Aug 14, 2001 at 08:55:56AM -0700, David O'Brien wrote:
> On Tue, Aug 14, 2001 at 09:54:04AM +0300, Ruslan Ermilov wrote:
> > > They produce the same output, but in the general case they do not need
> > > to.
> >
> > What I hear? Hell, then my solution (or something similar) should be
> > committed, as it at least unbreaks the 4.x -> 5.0 upgrade path, which
> > I am mostly concerned about (on the same arch).
>
> I never said they weren't the same format nor that it wouldn't be fixed.
> I said I wanted to try some things. NetBSD something simular to the
> patch below in their usr.bin/file/Makefile -- they build the .mgc files
> during build time. The patch to src/Makefile.inc is one way to implement
> the needed hooks.
>
Good.
> >From a correctness stand point, building the .mgc files at install time
> is the correct thing to do... or maybe we should do both -- doing the
> [re]creation of the .mgc files at install time in the cross-[arch-]build
> case.
>
Just to clarify. Nothing should be built in ${.OBJDIR} at install time,
as it may be read-only. The build in ${DESTDIR} is allowed, we, for
example, execute makewhatis(1) at the end of `installworld'. But this
"build" is implicit, i.e., it's not done by make dependencies. And
also note that only bootstrap-tools and utilities copied to the
${TMPPATH} as the first step of `installworld' are allowed during
`installworld'.
> +mkmagic: apprentice.c print-hacked.c
> + ${HOST_CC} -o mkmagic -DHAVE_CONFIG_H -DCOMPILE_ONLY \
> + -I${.CURDIR} -I${SRCDIR} ${.ALLSRC}
>
Whoa, cool!
That's what I wanted from the very beginning (-DCOMPILE_ONLY knob).
It then fits just nicely into the `build-tools' concept. And we
don't need this ugly HOST_CC hack for Makefile.inc1, as ${CC} is
set correctly during the `build-tools' stage. Let's don't reinvent
the wheel, and please try the attached patch instead.
Cheers,
--
Ruslan Ermilov Oracle Developer/DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.208
diff -u -r1.208 Makefile.inc1
--- Makefile.inc1 2001/08/04 18:25:38 1.208
+++ Makefile.inc1 2001/08/14 17:30:11
@@ -600,7 +600,8 @@
build-tools:
.for _tool in bin/csh bin/sh ${_games} gnu/usr.bin/cc/cc_tools ${_fortran} \
-${_libroken4} ${_libkrb5} lib/libncurses ${_share} usr.sbin/sysinstall
+${_libroken4} ${_libkrb5} lib/libncurses ${_share} usr.bin/file \
+usr.sbin/sysinstall
cd ${.CURDIR}/${_tool}; ${MAKE} build-tools
.endfor
Index: usr.bin/file/Makefile
===
RCS file: /home/ncvs/src/usr.bin/file/Makefile,v
retrieving revision 1.21
diff -u -r1.21 Makefile
--- usr.bin/file/Makefile 2001/08/08 16:19:30 1.21
+++ usr.bin/file/Makefile 2001/08/14 17:30:11
@@ -34,23 +34,29 @@
CFLAGS+= -DMAGIC='"${MAGICPATH}/magic"' -DBUILTIN_ELF -DELFCORE -DHAVE_CONFIG_H
CFLAGS+= -I${.CURDIR} -I${SRCDIR}
-CLEANFILES+= magic magic.mgc magic.mime.mgc magic.mime.PITA
+CLEANFILES+= mkmagic magic magic.mgc magic.mime.mgc magic.mime.PITA
MAGFILES= ${SRCDIR}/Header\
${SRCDIR}/Localstuff\
${SRCDIR}/Magdir/[a-z]*
-all: file magic magic.mgc magic.mime.mgc
+all: ${PROG} magic magic.mgc magic.mime.mgc
+build-tools: mkmagic
+
+mkmagic: apprentice.c print-hacked.c
+ ${CC} -DHAVE_CONFIG_H -DCOMPILE_ONLY \
+ -I${.CURDIR} -I${SRCDIR} -o ${.TARGET} ${.ALLSRC}
+
magic: ${MAGFILES}
cat ${.ALLSRC} > ${.TARGET}
-magic.mgc: file magic
- ./${PROG} -C -m magic
+magic.mgc: mkmagic magic
+ ./mkmagic magic
-magic.mime.mgc: file magic.mime
+magic.mime.mgc: mkmagic magic.mime
ln -sf ${SRCDIR}/magic.mime magic.mime.PITA
- ./${PROG} -C -m magic.mime.PITA
+ ./mkmagic magic.mime.PITA
mv magic.mime.PITA.mgc magic.mime.mgc
CLEANFILES+= print-hacked.c
Re: Cross builds and upgrade path from 4.x are broken in usr.bin/file
On Tue, Aug 14, 2001 at 09:54:04AM +0300, Ruslan Ermilov wrote:
> > They produce the same output, but in the general case they do not need
> > to.
>
> What I hear? Hell, then my solution (or something similar) should be
> committed, as it at least unbreaks the 4.x -> 5.0 upgrade path, which
> I am mostly concerned about (on the same arch).
I never said they weren't the same format nor that it wouldn't be fixed.
I said I wanted to try some things. NetBSD something simular to the
patch below in their usr.bin/file/Makefile -- they build the .mgc files
during build time. The patch to src/Makefile.inc is one way to implement
the needed hooks.
>From a correctness stand point, building the .mgc files at install time
is the correct thing to do... or maybe we should do both -- doing the
[re]creation of the .mgc files at install time in the cross-[arch-]build
case.
Index: Makefile.inc1
===
RCS file: /home/ncvs/src/Makefile.inc1,v
retrieving revision 1.208
diff -u -r1.208 Makefile.inc1
--- Makefile.inc1 2001/08/04 18:25:38 1.208
+++ Makefile.inc1 2001/08/13 23:42:09
@@ -199,6 +199,7 @@
WMAKEENV= ${CROSSENV} \
DESTDIR=${WORLDTMP} \
INSTALL="sh ${.CURDIR}/tools/install.sh" \
+ HOST_CC='env COMPILER_PATH=/usr/libexec:/usr/bin LIBRARY_PATH=/usr/lib
+/usr/bin/cc' \
PATH=${TMPPATH}
WMAKE= ${WMAKEENV} ${MAKE} -f Makefile.inc1
Index: usr.bin/file/Makefile
===
RCS file: /home/ncvs/src/usr.bin/file/Makefile,v
retrieving revision 1.21
diff -u -r1.21 Makefile
--- usr.bin/file/Makefile 2001/08/08 16:19:30 1.21
+++ usr.bin/file/Makefile 2001/08/14 15:53:21
@@ -45,13 +45,18 @@
magic: ${MAGFILES}
cat ${.ALLSRC} > ${.TARGET}
-magic.mgc: file magic
- ./${PROG} -C -m magic
+magic.mgc: mkmagic magic
+ ./mkmagic magic
-magic.mime.mgc: file magic.mime
+magic.mime.mgc: mkmagic magic.mime
ln -sf ${SRCDIR}/magic.mime magic.mime.PITA
- ./${PROG} -C -m magic.mime.PITA
+ ./mkmagic magic.mime.PITA
mv magic.mime.PITA.mgc magic.mime.mgc
+
+CLEANFILES+= mkmagic
+mkmagic: apprentice.c print-hacked.c
+ ${HOST_CC} -o mkmagic -DHAVE_CONFIG_H -DCOMPILE_ONLY \
+ -I${.CURDIR} -I${SRCDIR} ${.ALLSRC}
CLEANFILES+= print-hacked.c
print-hacked.c: print.c
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Cross builds and upgrade path from 4.x are broken in usr.bin/file
On Mon, Aug 13, 2001 at 01:30:15PM -0700, David O'Brien wrote: > On Fri, Aug 10, 2001 at 08:23:00PM +0300, Ruslan Ermilov wrote: > > > Your solution does not work. You're creating binary files in HOST > > > format during the build phase and expecting things such as alignment > > > and endianness to be the same as the TARGET format. Unless the tools > > > are built to output for either the appropriate architecture or in a > > > portable, binary format, you will have problems reading the file on > > > the TARGET platform. It probably works for you since you're doing a > > > 4.X->5.0 upgrade on the same platform. > > > > > What? ``file -C'' produces different output on Alpha and on i386? > > Are you sure? (Haven't checked myself.) > > They produce the same output, but in the general case they do not need > to. > What I hear? Hell, then my solution (or something similar) should be committed, as it at least unbreaks the 4.x -> 5.0 upgrade path, which I am mostly concerned about (on the same arch). (Currently, it is broken because ./file depends on libc.so.5 while in -STABLE it is still libc.so.4.) Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Cross builds and upgrade path from 4.x are broken in usr.bin/file
On Fri, Aug 10, 2001 at 08:23:00PM +0300, Ruslan Ermilov wrote: > > Your solution does not work. You're creating binary files in HOST > > format during the build phase and expecting things such as alignment > > and endianness to be the same as the TARGET format. Unless the tools > > are built to output for either the appropriate architecture or in a > > portable, binary format, you will have problems reading the file on > > the TARGET platform. It probably works for you since you're doing a > > 4.X->5.0 upgrade on the same platform. > > > What? ``file -C'' produces different output on Alpha and on i386? > Are you sure? (Haven't checked myself.) They produce the same output, but in the general case they do not need to. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Cross builds and upgrade path from 4.x are broken in usr.bin/file
On Sat, Aug 11, 2001 at 11:51:18AM -0700, Terry Lambert wrote: [...] > > > If this is really a goal, then you should redesign the > > > process and not put more and more tools into the "build tools" > > > category to work around these problems. > > > > Take a look at sysinstall/Makefile to have a better idea of what > > a "pure" build tool is, rtermcap. It is just the first incident > > (with file(1)) that it's also a build-tool for its own .mgc files. > > Mark is right, here. The idea of "build tools" is intrinsically > broken, given the goal (if it is a goal). > The build-tools stage is responsible for creating tools that are to be used only during `buildworld', and are not used/installed otherwise. The file(1) is special in that it produces the MD format, hence it is not suitable for build-tools. (I did not know that.) Cheers, -- Ruslan Ermilov Oracle Developer/DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
