Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work
Am 29. Juni 2017 18:55:59 GMT+08:00 schrieb Mark Millard : >I'm not currently set up to run more than head on >any of amd64, powerpc64, powerpc, aarch64, or armv6/7 >(which are all I target). And I'm in the middle of >attempting a fairly large jump to head -r320458 on >those. Oh, then I had misunderstood your previous mail. No worries, I'll gently proceed then. I expect to update gcc5 in the next 24 hours. >[In my normal/head environment I'm switching to lang/gcc7-devel >for gcc (from lang/gcc6 ) but I'm odd that way.] The compiler should be fine, it's a number of ports that are not (even blocking the move from GCC 5 to 6 as default). Gerald ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work
Am 28. Juni 2017 22:38:52 GMT+08:00 schrieb Mark Millard :
>A primary test is building lang/gcc5-devel under release/11.0.1
>and then using it under stable/11 or some draft of release/11.1.0 .
Thank you, Mark. Let me know how it went. In the meantime I'll prepare the
change for gcc5 itself.
>It looks like the the lang/gcc5-devel build still creates and
>uses the headers that go in include-fixed/ but that they are
>removed from $(STAGEDIR}${TARGLIB} 's tree before installation
>or packaging.
>
>So, if I understand right, lang/gcc5-devel itself still does use
>the adjusted headers to produce its own materials but when
>lang/gcc5-devel is used later it does not. Definitely
>something to be testing since it is a mix overall.
I am not worried about that since that should not cause any binary
incompatibilities (ABI). The problem we encountered was about source code and
API in a wide sense of that term.
>Is some form of exp-like run needed that tries to force use
>of a release/11.0.1 built lang/gcc5-devel (-r444563) to build
>other things under, say, stable/11 or some draft of
>release/11.1.0 ? Is this odd combination even possible
>currently?
I am not aware of it, and while originally I was thinking to request an -exp
run (after the GCC version update which is dragging due to broken ports), time
is not on our side and the change should be low risk.
> [altermative approach] But I guess that did not work out.
Not with my current level of connectivity and my notebook a dead brick on top
of that. And my preference is to still build, but stow away (unless explicitly
requested to keep).
>Eventually most of the lang/gcc* 's will need whatever
>technique is used.
Yes, agreed. Version 5 is most important since it's the default; then 6; 4.x is
for retro computing fans ;-), so 7 will then be next.
Gerald
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work
Hi everyone, I am testing a patch for gcc5-devel right now that will disable fixincludes (or rather its fixed files) being packaged. Should that work fine for you, I will push this back to gcc5 the following days. That said, the change that triggered this is what I would expect on CURRENT, not STABLE (and hence hoped we'd have more time for this change). My Internet connectivity right now is only slightly above pigeon speed, so sorry for any delays. Gerald ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition
On Mon, 1 May 2017, Mark Millard wrote: > and that mkheaders does more than just fixinc.sh > as far as changing headers goes, such as limits.h > and gsyslmits.h and syslimits.h . That's a good point, and I guess the *limits.h files do make sense to come from the compiler itself? > The fixincludes script is known to occasionally erroneously attempt > to "fix" the system headers installed so far. As the headers up to > this point are known to not require fixing, issue the following > command to prevent the fixincludes script from running: > > sed -i 's@\./fixinc\.sh@-c true@' gcc/Makefile.in > > (End quote) : > This still leaves the limits.h and gsystemlimits.h and > syslimits.h code in place but does block most of the > activity. Thanks for this pointer, Mark! I have earmarked this as the first approach to give a try soon, instead of completely yanking the fixincluded directory. Gerald ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition
On Sat, 29 Apr 2017, Dimitry Andric wrote: > This is because gcc's fixincludes process makes copies of certain system > headers (in this case, /usr/include/sys/types.h) with slight > modifications. Then, it places the directory containing the modified > headers at the front of the include search path. So far so good. > > Now, whenever sys/types.h is updated, as happened with the vm_ooffset_t > change, the header in gcc's own preferred directory might not match the > definitions which are expected, leading to compilation errors. >> If the port/package is builts from scratch, does this trigger the >> problem? > Yes, basically you need to rebuild all gcc ports from scratch, whenever > you update any system header that matches gcc's list of files it wants > to modify. That, or run the fixinc.sh script in ./libexec/gcc/$TARGETTRIPLET/$VERSION/install-tools/fixinc.sh. The proposed patch would help with that, but still require a manual run, hence my original question. On Sun, 30 Apr 2017, Konstantin Belousov wrote: > Am I right that Jung-uk fix replaces vm_ooffset_t and vm_pindex_t with > explicit int64_t and uint64_t use, as the course of action for gcc > fixincludes step ? If yes, I completely disagree. > > The change blocks any future changes to the type that might occur in the > base system, for the code compiled by gcc. End result might be as bad > as mismatched ABI, in the worst case. Okay, thanks for your feedback. > With all of the above, IMO most sane way to fix problems is to > rename fixincludes directory to some name which is ignored by gcc, > e.g. include-fixed -> include-fixed.saved. This can be done as > post-installation step in the ports. This is what I figured, too, and plan on giving a try. It probably warrants an -exp run to be on the safe side. On Sun, 30 Apr 2017, Dimitry Andric wrote: > I agree, it would be best to avoid storing any copies of system headers > completely. > > Maybe the port can have an option FIX_INCLUDES, which defaults to off? > I am not sure if there is anybody that really wants these 'fixed' > headers, though. :) There are two infrastructure improvements for the (current) GCC ports (orthogonal to a few simpler things I've been simplifying today in older ports) that I'd like to conclude first, otherwise there'll be too many balls in the air. ( https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218475 is the last hold-off on the first of them, in case anyone can give this a try. ;-) It is on my list to pursue directly afterwards, then. (Luckily this only hits with most -CURRENT versions of FreeBSD and older packages only.) Gerald ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition
On Thu, 27 Apr 2017, Jung-uk Kim wrote: >> I found the problem, but I do not know how to resolve this. When you >> install the GCC compiler from the PKG repository it appears to create a >> modified set of include files from the system (default?) include files >> (/usr/include). However, when the modified /usr/include/sys/types.h >> file is created, the typedef for vm_ooffset_t is modified, and there is >> no reference to __vm_ooffset_t that the compiler can resolve. >> >> < typedef __int64_t vm_ooffset_t; >> --- >> > typedef __vm_ooffset_t vm_ooffset_t; > ... > You have to rebuild lang/gcc from the ports tree to fix this problem. > > https://lists.freebsd.org/pipermail/freebsd-current/2017-February/064937.html Does this mean that the GCC port/package needs to be updated? If so, should I file a PR report on this issue? I (temporarily) fixed this problem by hand editting the modified types.h file and things seem to work. >>> I already wrote a patch (attached). :-) > If the maintainer (gerald) approves. CC'd. Thanks for bringing this to my attention. Can you please help me understand why this is necessary? If the port/package is builts from scratch, does this trigger the problem? Or is this only a question of an old package running on that new version of FreeBSD after these changes? (I am wondering whether just forcing a rebuild of that package is not going to have the same effect?) Gerald ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: GCC-4.6-20120608 has a corrupt archive or a bad checksum
John Merryweather Cooper wrote: > Bad distfile or checksum for lang/gcc46 The mirror you are using per your e-mail -- ftp://ftp-stud.fht-esslingen.de/pub/Mirrors/sources.redhat.com/ -- provides a broken image. I have done several downloads myself, from the original source and other mirrors, and always get the correct checksum (and a matching tarball), that is, the one matching gcc46/distinfo in FreeBSD Ports CVS. If you download directly from ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20120608/gcc-4.6-20120608.tar.bz2 and put that into ports/distfiles, that should work? Alternatively, download repeatedly until it hits a different mirror? Gerald ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Kernel option USER_LDT issues in -stable
Daniel Eischen <[EMAIL PROTECTED]> wrote: > I can see it being required in -current soon as threadsNG > is going to need it. I don't see the harm in making it > default in -stable, but I can't address any security concerns > (if there are any). Linux has been providing this for years (if not forever), and it really would be nice to be able to use the Wine port and other software, which is especially relevant for non-technical users, without having to build a custom kernel. (In fact, does it even make sense to have this as an option and not just provide this functionality unconditionally?) Gerald -- Gerald "Jerry" [EMAIL PROTECTED] http://www.dbai.tuwien.ac.at/~pfeifer/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
http://www.freebsd.org/releases/4.2R/errata.html
...is out of date and does not match the version found at ftp://ftp.FreeBSD.org/pub/FreeBSD/releases/i386/4.2-RELEASE/ERRATA.TXT I strongly feel that the version on the web should be up-to-date, and indeed this seems to have been the case for earlier releases. Also having *both* online versions say "This ERRATA.TXT file is obviously already out of date by definition" does not seem correct, either. Gerald -- Gerald "Jerry" [EMAIL PROTECTED] http://www.dbai.tuwien.ac.at/~pfeifer/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: passwd (still) broken in NIS environments
On Tue, 23 Jan 2001 [EMAIL PROTECTED] wrote: > Do you have the same crypting algorithm on both ends ? > (FreeBSD recently went to MD5 as a standard - Solaris most > likely is still using DES) Yes, the Solaris NIS Server is using DES. However, as we don't have problems logging in, just changing passwords, I assume this isn't the reason? Or does passwd use MD5 nevertheless?? That might be an explanation! Hmm... Gerald -- Gerald "Jerry" [EMAIL PROTECTED] http://www.dbai.tuwien.ac.at/~pfeifer/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
Re: Adding xpm to linux_base: your comments please
On Tue, 7 Sep 1999, Marcel Moolenaar wrote: > I recently received the request (accompanied by patches to emphasize the > importance :-) from Junho Choi to add xpm to linux_base. xpm is used by X > binaries, including Netscape. I'm in doubt. What's your opinion? I think it would be great! xpm is really quite widely used. Gerald -- Gerald "Jerry" [EMAIL PROTECTED] http://www.dbai.tuwien.ac.at/~pfeifer/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-stable" in the body of the message
