Thread: MacOS X 10.2
Greetings;
I just got my shiny new copy of MacOS X 10.2 -- Err. That would be my
fuzzy, spotted new version of MacOS X. :)
In the process of rebuilding my /usr/local tree, postgreSQL failed to
build. I had no trouble with 10.1.
The make bailed with:
========================================================================
============================
gcc -traditional-cpp -g -O2 -Wall -Wmissing-prototypes
-Wmissing-declarations -I../../../../src/include -c -o sem.o sem.c
In file included from sem.c:30:
../../../../src/include/port/darwin/sem.h:66: warning: `union semun'
declared inside parameter list
../../../../src/include/port/darwin/sem.h:66: warning: its scope is
only this definition or declaration, which is probably not what you want
../../../../src/include/port/darwin/sem.h:66: warning: parameter has
incomplete type
sem.c:67: warning: `union semun' declared inside parameter list
sem.c:68: parameter `arg' has incomplete type
make[4]: *** [sem.o] Error 1
make[3]: *** [darwin.dir] Error 2
make[2]: *** [port-recursive] Error 2
make[1]: *** [all] Error 2
make: *** [all] Error 2
========================================================================
============================
I poked around a bit and found semun defined in /usr/include/sem.h. I
tried some obvious things -- like defining the
thing, including the correct file, etc... No luck.
This was postgresql-7.2.2.
Thanx in advance for your efforts.
-mitch richling
PS: I love this database. I was a diehard Oracle user about a year
ago, and now I only use it if someone makes me!
PostgreSQL RULES
Ok Ok Ok. I didn't look hard enough at the source code! I looked at the source code, and figured out that sem.h had been added to the src/ tree because 10.1 didn't have one -- why would Apple do that? Grr. Anyhow, the fix is simple: Undo all the good work that was done to fix the problem in 10.1! I got everything working by replacing #include "port/darwin/sem.h" with #include <sys/sem.h> src/backend/storage/ipc/ipc.c src/backend/storage/lmgr/proc.c src/backend/storage/lmgr/spin.c and by removing the target/dependancy for sem.o in src/backend/port/darwin/Makefile. I would have sent diffs, but my changes are not appropriate to be merged in. All I did was the minimum to get it to compile on my system, and not what needs to be done in the production code. For example, my changes break a compile on 10.1 if that's important to you. Someone needs to think about how to fix the code up so that it's production worthy. Anyhow. Thanks for the great DB! On Sunday, August 25, 2002, at 01:23 AM, richmit wrote: > Greetings; > > I just got my shiny new copy of MacOS X 10.2 -- Err. That would be my > fuzzy, spotted new version of MacOS X. :) > > In the process of rebuilding my /usr/local tree, postgreSQL failed to > build. I had no trouble with 10.1. > > The make bailed with: > > > ======================================================================= > ============================= > gcc -traditional-cpp -g -O2 -Wall -Wmissing-prototypes > -Wmissing-declarations -I../../../../src/include -c -o sem.o sem.c > In file included from sem.c:30: > ../../../../src/include/port/darwin/sem.h:66: warning: `union semun' > declared inside parameter list > ../../../../src/include/port/darwin/sem.h:66: warning: its scope is > only this definition or declaration, which is probably not what you > want > ../../../../src/include/port/darwin/sem.h:66: warning: parameter has > incomplete type > sem.c:67: warning: `union semun' declared inside parameter list > sem.c:68: parameter `arg' has incomplete type > make[4]: *** [sem.o] Error 1 > make[3]: *** [darwin.dir] Error 2 > make[2]: *** [port-recursive] Error 2 > make[1]: *** [all] Error 2 > make: *** [all] Error 2 > ======================================================================= > ============================= > > I poked around a bit and found semun defined in /usr/include/sem.h. I > tried some obvious things -- like defining the > thing, including the correct file, etc... No luck. > > This was postgresql-7.2.2. > > Thanx in advance for your efforts. > > > -mitch richling > > PS: I love this database. I was a diehard Oracle user about a year > ago, and now I only use it if someone makes me! > PostgreSQL RULES >
I'm trying to compile 7.3.2 on Solaris 7 with the built-in Kerberos IV support. To avoid conflicts I do not have ssl support turned on. Configure goes and looks for libkrb with some routine that is there. Then it checks for libdes with des_encrypt. Now first of all there is no libdes on Sol7. There's only the one that was put in when I added ssl. Second there is no des_encrypt in openssl. Third there is no des_encrypt in the Heimdal/KTH-KRB implementation either. So is that routine actually one that's used? If so where did it come from, and whose implementation of what actually provided it? Or has everyone just abandoned K4 and we should forget about it? (Yes, I know all about the latest problems found with K4. As long as you are using patched/old MIT code and not doing cross-realm authentication you're probably better off than with a lot of versions of K5.) -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
"Henry B. Hotz" <hotz@jpl.nasa.gov> writes:
> Or has everyone just abandoned K4 and we should forget about it?
It's entirely possible that you're the only one using K4 with PG;
I can't recall having heard from anyone else recently. If it's
broken, send us patches ...
regards, tom lane
At 1:45 PM -0500 4/4/03, Tom Lane wrote: >"Henry B. Hotz" <hotz@jpl.nasa.gov> writes: >> Or has everyone just abandoned K4 and we should forget about it? > >It's entirely possible that you're the only one using K4 with PG; >I can't recall having heard from anyone else recently. If it's >broken, send us patches ... If I do patching I'll send patches. I didn't want to install K5 on this machine when K4 is already there and the KDC I'm using supports K4. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu
Henry B. Hotz writes: > Configure goes and looks for libkrb with some routine that is there. > Then it checks for libdes with des_encrypt. Now first of all there > is no libdes on Sol7. There's only the one that was put in when I > added ssl. Second there is no des_encrypt in openssl. Third there > is no des_encrypt in the Heimdal/KTH-KRB implementation either. > > So is that routine actually one that's used? If so where did it come > from, and whose implementation of what actually provided it? Last time I reworked that code I used the KTH version to check it, so your report puzzles me a little. Basically we just want to make sure that the Kerberos installation is sufficient before proceeding. Feel free to suggest improvements. -- Peter Eisentraut peter_e@gmx.net
At 1:55 AM +0200 4/5/03, Peter Eisentraut wrote: >Henry B. Hotz writes: > >> Configure goes and looks for libkrb with some routine that is there. >> Then it checks for libdes with des_encrypt. Now first of all there >> is no libdes on Sol7. There's only the one that was put in when I >> added ssl. Second there is no des_encrypt in openssl. Third there >> is no des_encrypt in the Heimdal/KTH-KRB implementation either. >> >> So is that routine actually one that's used? If so where did it come >> from, and whose implementation of what actually provided it? > >Last time I reworked that code I used the KTH version to check it, so your >report puzzles me a little. Basically we just want to make sure that the >Kerberos installation is sufficient before proceeding. Feel free to >suggest improvements. /usr/lib/libdes.a on NetBSD 1.6Q has des_encrypt1, des_encrypt2, and des_encrypt3, but no unnumbered one. I don't know for sure if that library is from ssl or from Heimdal/KTF-KRB, but I suspect the latter. They have definitely done something to rationalize openssl with Heimdal so it may be a merger of some kind. OSX has an _k5_des_encrypt routine in libdes425.dylib. Can't find anything in Solaris 7, which is actually odd because I thought there was a cryptsoft libdes included with Solaris 2.6. Perhaps my memory is fading though. That was a while ago. Looking further on Sol7 I do find: nm libcrypto.a | fgrep des_encr [67] | 448| 28|FUNC |GLOB |0 |2 |_ossl_old_des_encrypt [69] | 480| 28|FUNC |GLOB |0 |2 |_ossl_old_des_encrypt2 [70] | 512| 32|FUNC |GLOB |0 |2 |_ossl_old_des_encrypt3 in /usr/local/lib. Interesting. Now back to /usr/lib: nm libcrypt.a | fgrep des_encr [12] | 0| 0|NOTY |GLOB |0 |UNDEF |_des_encrypt libcrypt.a[des_encrypt.o]: [6] | 0| 472|FUNC |GLOB |0 |2 |_des_encrypt1 [1] | 0| 0|FILE |LOCL |0 |ABS |des_encrypt.c [5] | 0| 472|FUNC |WEAK |0 |2 |des_encrypt1 [32] | 604| 40|FUNC |GLOB |0 |2 |_des_encrypt [38] | 0| 0|NOTY |GLOB |0 |UNDEF |_des_encrypt1 [31] | 604| 40|FUNC |WEAK |0 |2 |des_encrypt [25] | 444| 160|FUNC |LOCL |0 |2 |des_encrypt_nolock Bingo!!!!!!!!!!!!! Going back to NetBSD and OSX I find that they both have the numbered versions in /usr/lib/libcrypto... Still no unnumbered version. Well, if there's built-in kerb5 then I would use that over kerb4 anyway. Kerberos 4 is only suitable for simple installations with no cross-realm authentication needed now. -- The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz@jpl.nasa.gov, or hbhotz@oxy.edu