Re: stdout changes break some ports
Terry Lambert wrote:
Kris Kennaway wrote:
How does one fix this in a library? I've been moving the
initialization to main() for applications.
Use assembly glue to put it in a linker set that gets pulled
in by the .init code.
This will only work for user space code, since it depends in
the crt0 treating it like a C++ binary (linker sets are a C++
feature which FreeBSD uses all over anyway).
Realizing that I think this is the wrong way to fix this problem,
add the following to your library:
foo.c:
#include sys/linker_set.h
static void
run_before_main(void)
{
... /* my crap */
}
TEXT_SET(__CTOR_LIST__, run_before_main);
If you want something run on rundown, use:
TEXT_SET(__DTOR_LIST__, run_after_main);
(or just use atexit(3), if you can live with the registration
polluting your source code).
Doing the code this way will guarantee that your code will
work on any FreeBSD supported platform where C++ works.
-- Terry
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: stdout changes break some ports
At 10:46 PM -0800 3/30/02, Kris Kennaway wrote: On Sun, Mar 24, 2002 at 05:54:36PM -0800, Kris Kennaway wrote: On Sun, Mar 24, 2002 at 06:43:13PM -0700, M. Warner Losh wrote: No. This isn't something that is guaranteed to work per the standards, iirc. The proper fix is to put the initializer in main. OK. Someone needs to go and fix those 84 ports then. How does one fix this in a library? I've been moving the initialization to main() for applications. If all else fails, have some global static variable, and check the value in the routine(s) which care. if the flag variable is still zero, then initialize the stdout variable and change the flag variable to 1. I imagine there's plenty of smarter ways to do it though. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: stdout changes break some ports
* Kris Kennaway [EMAIL PROTECTED] [2002-03-31 08:48]: On Sun, Mar 24, 2002 at 05:54:36PM -0800, Kris Kennaway wrote: On Sun, Mar 24, 2002 at 06:43:13PM -0700, M. Warner Losh wrote: : David O'Brien committed a workaround to the clog port yesterday to : move the initializer to main() instead of trying to do it statically. : : Is this something which is supposed to work? No. This isn't something that is guaranteed to work per the standards, iirc. The proper fix is to put the initializer in main. OK. Someone needs to go and fix those 84 ports then. How does one fix this in a library? I've been moving the initialization to main() for applications. Unfortunately it is not so straight forward. IMO, the best solution is to initialise to NULL and test for this when called and change them to stdin and stdout where necessary. This is a little overhead but the cleanest way IMO. I heard of the possibility to do things like static FILE*fpout=NULL; #define fp (fpout?fpout:stdout) But I never tested this. I can help you a little bit changing this in the concerning libraries, if you want, since this seems to be a lot of work. Regards, Olli -- Department of Computing Science Federal Armed Forces University Munich http://ist.unibw-muenchen.de/People/obraun/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: stdout changes break some ports
Garance A Drosihn wrote: How does one fix this in a library? I've been moving the initialization to main() for applications. If all else fails, have some global static variable, and check the value in the routine(s) which care. if the flag variable is still zero, then initialize the stdout variable and change the flag variable to 1. I imagine there's plenty of smarter ways to do it though. The smartest way would be to have all zeros be the correct default for the initial state data. The next smartest way would be to pick the first zeroed value as an initialized variable, and check it each time, setting it to 1, once the initialization has taken place. The next smartest way would be to treat it as if it were a static class declaration that needed to be automatically constructed before it could be used (see the code for this in my previous posting). This one is kind of a tossup, since it gets the extra check out of the main path, but relies on weird glue code. The least smartest way would be to create an init function which had to be called by main() before you could use stdio, unlike all other UNIX systems on the planet. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: stdout changes break some ports
On Sun, Mar 24, 2002 at 05:54:36PM -0800, Kris Kennaway wrote: On Sun, Mar 24, 2002 at 06:43:13PM -0700, M. Warner Losh wrote: : David O'Brien committed a workaround to the clog port yesterday to : move the initializer to main() instead of trying to do it statically. : : Is this something which is supposed to work? No. This isn't something that is guaranteed to work per the standards, iirc. The proper fix is to put the initializer in main. OK. Someone needs to go and fix those 84 ports then. How does one fix this in a library? I've been moving the initialization to main() for applications. Kris msg36818/pgp0.pgp Description: PGP signature
Re: stdout changes break some ports
Kris Kennaway wrote: How does one fix this in a library? I've been moving the initialization to main() for applications. Use assembly glue to put it in a linker set that gets pulled in by the .init code. This will only work for user space code, since it depends in the crt0 treating it like a C++ binary (linker sets are a C++ feature which FreeBSD uses all over anyway). I'm not totally convinced this is really the way to fix this, since I'm not totally convinced that this isn't an introduced problem, rather than a real problem (e.g. perhaps the stdio changes were not completely and totally well thought out, if how to handle this problem wasn't part of the changes). If it's now a requirement, it's very tempting to put the code in the entry code, before it even calls main (e.g. in crt0 proper, rather than in a linker set crt0 knows about). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: stdout changes break some ports
On Sun, 24 Mar 2002, Kris Kennaway wrote: OK. Someone needs to go and fix those 84 ports then. http://bento.freebsd.org/errorlogs/5-latest-4-latest.html Has anyone contacted the maintainers? I'm sure that not all of them are on this list. It may be a good way to get a slightly more knowledgeable user base exposed to -current, as well as getting the ports fixed. -- We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory. - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: stdout changes break some ports
On Mon, Mar 25, 2002 at 09:30:39PM -0800, Doug Barton wrote: On Sun, 24 Mar 2002, Kris Kennaway wrote: OK. Someone needs to go and fix those 84 ports then. http://bento.freebsd.org/errorlogs/5-latest-4-latest.html Has anyone contacted the maintainers? I'm sure that not all of them are on this list. It may be a good way to get a slightly more knowledgeable user base exposed to -current, as well as getting the ports fixed. Yeah, that's something I'm going to do once the current package run finishes. I've held off doing it in the recent past since there were a lot of spurious failures caused by problems with bento, but I think this run is entirely free of such problems, and it's only ports which are truly broken that are showing up. Kris msg36578/pgp0.pgp Description: PGP signature
stdout changes break some ports
The changes to the definitions of stdout/stdin/stderr from a while back caused a number of ports to break (somewhere around 84, according to bento). For example, the cap port fails like this: http://bento.freebsd.org/errorlogs/5-latest/cap-6.0.198.log cc -DBYTESWAPPED -DPHASE2 -O -I/mnt/ports/net/cap/work/cap60 -DLWSRV_LPR_LOG -DSTAT_CACHE -DREREAD_AFPVOLS -DUSR_FILE_TYPES -DCREATE_AFPVOL=\mac\ -DPID_FILE=\/var/run/aufs.pid\ -DUSEVPRINTF -c ablog.c ablog.c:69: initializer element is not constant where the offending line is: static FILE *lfp = stderr; David O'Brien committed a workaround to the clog port yesterday to move the initializer to main() instead of trying to do it statically. Is this something which is supposed to work? Kris msg36530/pgp0.pgp Description: PGP signature
Re: stdout changes break some ports
In message: [EMAIL PROTECTED] Kris Kennaway [EMAIL PROTECTED] writes: : The changes to the definitions of stdout/stdin/stderr from a while : back caused a number of ports to break (somewhere around 84, according : to bento). For example, the cap port fails like this: : : http://bento.freebsd.org/errorlogs/5-latest/cap-6.0.198.log : : cc -DBYTESWAPPED -DPHASE2 -O -I/mnt/ports/net/cap/work/cap60 -DLWSRV_LPR_LOG :-DSTAT_CACHE -DREREAD_AFPVOLS -DUSR_FILE_TYPES -DCREATE_AFPVOL=\mac\ :-DPID_FILE=\/var/run/aufs.pid\ -DUSEVPRINTF -c ablog.c : ablog.c:69: initializer element is not constant : : where the offending line is: : : static FILE *lfp = stderr; : : David O'Brien committed a workaround to the clog port yesterday to : move the initializer to main() instead of trying to do it statically. : : Is this something which is supposed to work? No. This isn't something that is guaranteed to work per the standards, iirc. The proper fix is to put the initializer in main. The pain level of going back to something the old style is too high to even contemplate reverting. The C standard says: secont 7.19 stderr stdin stdout which are expressions of type ``pointer to FILE'' that point to the FILE objects associated, respectively, with the standard error, input, and output streams. 213The primary use of the freopen function is to change the file associated with a standard text stream (stderr, stdin, or stdout), as those identifiers need not be modifiable lvalues to which the value returned by the fopen function may be assigned. stderr macro, 7.19.1, 7.19.2, 7.19.3 Notice that it doesn't say that stderr is a compile time constant. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: stdout changes break some ports
On Sun, Mar 24, 2002 at 06:43:13PM -0700, M. Warner Losh wrote: : David O'Brien committed a workaround to the clog port yesterday to : move the initializer to main() instead of trying to do it statically. : : Is this something which is supposed to work? No. This isn't something that is guaranteed to work per the standards, iirc. The proper fix is to put the initializer in main. OK. Someone needs to go and fix those 84 ports then. http://bento.freebsd.org/errorlogs/5-latest-4-latest.html is a better resource for finding these than the complete list of build logs, because it only shows the ones which fail in 5.0 but build in 4.x (we have an awful lot of ports which are just completely broken) Kris msg36533/pgp0.pgp Description: PGP signature
