Re: Making PostgreSQL 7.4 (CVS) work properly on OS X 10.3 (7B85)
От | Bob Ippolito |
---|---|
Тема | Re: Making PostgreSQL 7.4 (CVS) work properly on OS X 10.3 (7B85) |
Дата | |
Msg-id | ECDE30AF-1218-11D8-AD77-000A95686CD8@redivi.com обсуждение исходный текст |
Ответ на | Re: Making PostgreSQL 7.4 (CVS) work properly on OS X 10.3 (7B85) (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: Making PostgreSQL 7.4 (CVS) work properly on OS X 10.3 (7B85)
|
Список | pgsql-hackers |
On Nov 8, 2003, at 1:13 PM, Tom Lane wrote: > Bob Ippolito <bob@redivi.com> writes: >> On Nov 8, 2003, at 12:31 AM, Tom Lane wrote: >>> I have just in the past couple hours realized that ps_status.c is >>> seriously broken on OS X 10.3. > >> Er... I meant memcmp.. Have you tried removing the system.c hack? >> That's what fixed it for me. > > AFAICT system.c hasn't got anything to do with the problem that I'm > seeing; it's purely a matter of ps_status.c clobbering argv[] contents > that the dynamic loader depends on for some weird reason. It looks > like Apple's implementation stores a copy of the original argc count, > and there is a bit of code in the loader that for some reason is > examining each argv string from 0..original_argc-1. Who knows why :-( > ... but where we set save_argv[1] to NULL, we create a null pointer > crash in the loader. Take that out, no crash. You would not see this > crash if you started the postmaster with no command-line arguments, > btw. > > I'm planning to change ps_status so that instead of zeroing > save_argv[1], it makes all the original argv strings be pointers to "" > except for argv[0]. It may be causing problems because dyld does this thing called @executable_path substitution so it can find dylibs relative to the executable. Also, the WindowServer and several other things (CoreFoundation, Foundation) use argv[0] to determine whether the executable is inside a bundle or not. I don't think OS X people would make a big fuss about argv[0] not being as useful as it is on other platforms, personally I'd just take it out if it's not working. > As for getting rid of system.c, I am not eager to do that since it > would > certainly break compatibility with OS X 10.1. We could conditionally > compile it out perhaps. Do you know what #define symbol we could test > for to determine which OS X version we are on? See /usr/include/AvailabilityMacros.h -bob
В списке pgsql-hackers по дате отправления: