Re: [Lynx-dev] configure-script issue
>> Specifically, when I run it with CC set to cc -g, [...] > I created the macro after dealing with users who would put C > preprocessor options in $CC (which for lynx will cause it to not > build the configuration summary page as expected, for ncurses will > cause interesting build failures, etc) or would load up $CC with > optimization/debugging options (similar problems, with complaints > when it didn't evaluate in the expected order). > A warning message is just a reminder... Except it's not just a warning message. The script also insists on prying the options off $CC and putting them elsewhere. > CFLAGS is the proper place for compiler options (standard), > CPPFLAGS is the place for C preprocessor options [...] When I'm trying to turn debugging on, I've run into way too many build systems that will use some setting most of the time but then lose it other times. For example, some build procedures use CFLAGS when compiling .c to .o, but not when linking .o files together into an executable. The most reliable way I've found of getting -g set everywhere is to make it part of $CC. (It is at least somewhat important that the compilers I use ignore -g, rather than erroring out, when doing something for which it's not relevant.) I've even occasinoally run into some that don't provide a way to set CFLAGS, or make it obscure and undocumented enough that they might as well not. >> So if I'm going to end up building 2.9.0dev.10, I'm going to have to >> resurrect the kludge I used before: create a script (I called it >> cc-g) that runs cc -g "$@", and tell configure to use that. > I do that for compiler warnings, but not for optimization/debugging. For routine use, I do too: I have a script, wgcc, that runs gcc with a suitable set of options depending on the particular compiler/version in use. For example, one of the more heavily used of the lists of flags is -Werror -W -Wall -Wpointer-arith -Wcast-qual -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wno-uninitialized -Wno-sign-compare -Wno-missing-field-initializers -Wno-pointer-sign -Wno-format-zero-length. I don't always want -g, but I often do. When I was building that lynx, performance was very much secondary to debuggability. > I do this with all C programs - lynx isn't special in that regard. Then I guess I just haven't had occasion to build much else you maintain. :-) /~\ The ASCII Mouse \ / Ribbon Campaign X Against HTMLmo...@rodents-montreal.org / \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
Re: [Lynx-dev] configure-script issue
On Thu, Feb 03, 2022 at 03:26:34PM -0500, Mouse wrote: > I wrote, earlier today, of trying to rebuild a past lynx install, > saying > > > This led me to rediscover that the configure script for that version > > appears to be broken. > > I fetched the current .tar.bz2, which unpacked into lynx2.9.0dev.10. > Turns out the configure script is still broken, just in a trivially > different way. (Aside from all the ways that inhere in using configure > scripts at all, that is.) > > Specifically, when I run it with CC set to cc -g, in order to get -g on > all compiler runs, the configure script calls this broken. The old > script then claimed this was a misuse of $CC. The modern script > doesn't call it _mis_use, but it does still - like the old one - someone complained about the word "misuse" I created the macro after dealing with users who would put C preprocessor options in $CC (which for lynx will cause it to not build the configuration summary page as expected, for ncurses will cause interesting build failures, etc) or would load up $CC with optimization/debugging options (similar problems, with complaints when it didn't evaluate in the expected order). A warning message is just a reminder... CFLAGS is the proper place for compiler options (standard), CPPFLAGS is the place for C preprocessor options (originally GNU make, but adopted in autoconf -- autoconf introduced DEFS, unnecessarily) dnl CF_CC_ENV_FLAGS version: 10 updated: 2020/12/31 18:40:20 dnl --- dnl Check for user's environment-breakage by stuffing CFLAGS/CPPFLAGS content dnl into CC. This will not help with broken scripts that wrap the compiler dnl with options, but eliminates a more common category of user confusion. dnl dnl In particular, it addresses the problem of being able to run the C dnl preprocessor in a consistent manner. dnl dnl Caveat: this also disallows blanks in the pathname for the compiler, but dnl the nuisance of having inconsistent settings for compiler and preprocessor dnl outweighs that limitation. > complain and pull the -g off $CC and put it...somewhere else; configure > code is sufficiently twisted I'm not entirely sure where. > > So if I'm going to end up building 2.9.0dev.10, I'm going to have to > resurrect the kludge I used before: create a script (I called it cc-g) > that runs cc -g "$@", and tell configure to use that. I do that for compiler warnings, but not for optimization/debugging. > But this leads me to ask: why do this? Is there something wrong with > wanting a specific option on _all_ cc runs? Or is there some other way > to specify that? Doing this has worked with every other such thing > I've tried, and it strikes me as remarkably obnoxious for the script to > think it knows better than I do how the compiler should be run in my > environment, forcing me to workarounds such as the cc-g script I > sketched above. (I notice other examples of this, such as the way it > maps c[1-9][0-9] to clang with some option, if clang is detected; that's because clang's c89/c99 wrappers are broken (especially on MacOS) to the point that they've become unusable. (I test-compile with c89, c99, gcc with different levels of warnings, clang and any other compiler which I have on a given machine). https://invisible-island.net/personal/lint-tools.html#tool_clang > fortunately, I'm not trying to use clang, so I can ignore that in > practice - but there certainly are plenty of ways it could cause the > build to break when just using what the user told it to would work.) > > But lynx is so sane in so many other respects this quite stands out, > leading me to ask what's behind it and why the complaint doesn't > explain either why it's a bad idea to want to specify options on all cc > runs or what the correct way to do so is. I do this with all C programs - lynx isn't special in that regard. -- Thomas E. Dickey https://invisible-island.net ftp://ftp.invisible-island.net signature.asc Description: PGP signature
Re: [Lynx-dev] lynx word bleeding?
Hi Ian, yes we have been here before. Still, I doubt creating my own lynx.dfg file will fix my greater issue, why this new compile of lynx locks up if Attaching a file, or sending an email with an attachment in my basic gmail account now. It also does not allow for some kinds of downloads in that account either. It is not gmail doing it, I get a 408 time out error, but can send things just fine using the older edition of lynx we have here. Karen On Thu, 3 Feb 2022, Ian Collier wrote: On Wed, Feb 02, 2022 at 11:18:23PM -0500, Karen Lewellen wrote: Ian you indicate that this cannot be saved on the options menu, meaning it must be corrected where ever the compile or main lynx.cfg is stored? That is correct; and also the lynx.cfg contains settings that dictate whether options can be saved on the options page, so it is possible to change that too. I know we have been here before, but you can write a lynx.cfg file just for your own account and run Lynx with the "-cfg FILENAME" option to use it. imc
Re: [Lynx-dev] lynx word bleeding?
So Dan, yes, I have my own file, so what specificly would I put in there for that site? Would it be a rule? Thanks in advance Chime
Re: [Lynx-dev] lynx word bleeding?
This is why having your own version of lynx.cfg in your home directory and calling it helps with individual preferences. On Thu, 3 Feb 2022, Karen Lewellen wrote: > Yes chime, it is not there. > I am told by dreamhost that it tends to be in a lynx.cfg that is > stored elsewhere. > although it was I believe in their 2.8.9dev.16. > > So I changed it in shellworld 2.9.0dev.5, and it worked. > you were able to save the option? > > > > On Wed, 2 Feb 2022, Chime Hart wrote: > > > Well, I took a look in an options menu in an older LYNX on Shellworld, where > > that particular setting is not there at all. On my Debian system with a > > current LYNX, I can switch over to html-and-yes I can enjoy that page. > > Chime > > > > > > -- ent- XR
