Missing headers Windows NT port

Hi,

I am experiencing missing header files. I am not suprised but I would like
to have any missing header file. If I have them I could attempt to write
/find them on my system. Can I access them throught the internet or is
someone kind enought to send them to me on request (Hugo??)?

At this moment I miss: <sys/ipc.h> and <sys/un.h>

TIA

Joost

Here they are from BSDI.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Hi,

I am experiencing missing header files. I am not suprised but
I would like
to have any missing header file. If I have them I could
attempt to write
/find them on my system. Can I access them throught the internet or is
someone kind enought to send them to me on request (Hugo??)?

At this moment I miss: <sys/ipc.h> and <sys/un.h>

Hi!

Have you checked that the SysV IPC functions actually exist? Last time I
checked, SysV shared memory was not implemented in cygwin32, and that was
the reason the headers were not there. This was some time ago, so they may
well have implemented them now - but then my guess would be that they had
included the headers too.
Anyway. It might be worth checking before you get too dug-in to other parts.
I believe this is a central part of the backend, so you will probably have a
lot of trouble unless you can find a working implementation of it.

//Magnus

Hi!

Have you checked that the SysV IPC functions actually exist? Last time I
checked, SysV shared memory was not implemented in cygwin32, and that was
the reason the headers were not there. This was some time ago, so they may
well have implemented them now - but then my guess would be that they had
included the headers too.
Anyway. It might be worth checking before you get too dug-in to other parts.
I believe this is a central part of the backend, so you will probably have a
lot of trouble unless you can find a working implementation of it.

Yes, you will need some sort of shared memory, even if it only a file
that can be mmap'ed into the memory of each backend. Hopefully they
have something that will work.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

Hi Magnus,

I found a working (enough) implementation. In fact This afternoon I
succeeeded in a complete compile just ip to "All of PostgreSQL is
successfully made. Ready to install."

Joosty

[Charset iso-8859-1 unsupported, filtering to ASCII...]

Hi Magnus,

I found a working (enough) implementation. In fact This afternoon I
succeeeded in a complete compile just ip to "All of PostgreSQL is
successfully made. Ready to install."

Wow, that's pretty amazing.

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

I'm impressed so far.

Getting ahead of myself...

What the overhead of the cygwin32 environment? (price, etc.)

This would make a nice binary distribution, eh? Such a distribution could
put PostgreSQL in the hands of many.

Bruce Momjian wrote:

Hi David,

I'm impressed so far.

Yeah, it's a wonderfull world ;-)

Getting ahead of myself...

What the overhead of the cygwin32 environment? (price, etc.)

Nop. Nothing Nada, all GNU.

This would make a nice binary distribution, eh? Such a
distribution could
put PostgreSQL in the hands of many.

The more the marrier. Let's push Backoffice of the markt (A complete GNU
based backoffice, ready to run on all popular OS's). (I am not really making
a joke here, I have a dream... ;-))

Joost

I'm not sure what the cygwin32 environment entails, but I'm a Windows
programmer (since Windows 2.0!) and I want to produce a Win32-native
version of PostgreSQL anyway. I was waiting until the 6.4 excitement died
down. Looks like Joost beat me to the punch. :-)

Aha, I read Joost's reply as I was reading this. I know that the GNU
thing is a problem for PG'ers. But if we can get the code working, Joost,
I can go back and un-GNU it. That is, I can do what I was planning on
doing anyway -- do a Win32 port without anybody else's tools. It will
help immensely if we start seeing what will go wrong under Windows. See
where I'm coming from? BTW: what compiler are you using for this effort?

But I agree that a Win32 port would get PG into the "hands of the masses."
My current needs are that it run on Solaris and NT, but I'd *like* it to
run well on 95 as well.

Michael

On Fri, 11 Sep 1998, David Hartwig wrote:

[Charset iso-8859-1 unsupported, filtering to ASCII...]

Hi David,

I'm impressed so far.

Yeah, it's a wonderfull world ;-)

Getting ahead of myself...

What the overhead of the cygwin32 environment? (price, etc.)

Nop. Nothing Nada, all GNU.

We only have a GNU problem about including GNU stuff INTO the source
tree, because it GNU'ifies our BSD license. Other than that, we all use
GNU stuff.

This would make a nice binary distribution, eh? Such a
distribution could
put PostgreSQL in the hands of many.

The more the marrier. Let's push Backoffice of the markt (A complete GNU
based backoffice, ready to run on all popular OS's). (I am not really making
a joke here, I have a dream... ;-))

Joost

-- 
Bruce Momjian                          |  830 Blythe Avenue
maillist@candle.pha.pa.us              |  Drexel Hill, Pennsylvania 19026
  +  If your life is a hard drive,     |  (610) 353-9879(w)
  +  Christ can be your backup.        |  (610) 853-3000(h)

On Fri, 11 Sep 1998, Bruce Momjian wrote:

[Charset iso-8859-1 unsupported, filtering to ASCII...]

Hi David,

I'm impressed so far.

Yeah, it's a wonderfull world ;-)

Getting ahead of myself...

What the overhead of the cygwin32 environment? (price, etc.)

Nop. Nothing Nada, all GNU.

We only have a GNU problem about including GNU stuff INTO the source
tree, because it GNU'ifies our BSD license. Other than that, we all use
GNU stuff.

Actually, I don't think we could if we even wanted to...the BSD
licencse itself states that its freely distributable as long as the
copyright stays in tact...so, if we were to put GPL code into it, would we
be breaking the BSD copyright :)

Marc G. Fournier
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org

Actually, I don't think we could if we even wanted to...the BSD
license itself states that its freely distributable as long as the
copyright stays in tact...so, if we were to put GPL code into it,
would we be breaking the BSD copyright :)

I don't mean to start the license thing again, and it's OK to ignore
this, but...

The copyright from UCB seems to allow unlimited use, modification, and
distribution, and asks that the copyright notice be included with the
code. afaik the main purpose of the copyright notice is to ensure that
UCB has some credit for the work they and their sponsors have done, and
to ensure that there is a liability disclaimer for same. Would the
inclusion of a GPL addendum or GPL code be at odds with that, as long as
the UCB license continues to be included and prominently displayed? I
have a hard time seeing how, but since lawyers are in a different world
than I maybe it's beyond me :)

- Tom

On Mon, Sep 14, 1998 at 01:55:31AM +0000, Thomas G. Lockhart wrote:

to ensure that there is a liability disclaimer for same. Would the
inclusion of a GPL addendum or GPL code be at odds with that, as long as
the UCB license continues to be included and prominently displayed? I

Just an example. GPL allows to link against a non-GPLed library only if that
library is part of the opertaing system. UCB license allows that. So if we
were to add such a library we cannot do that if we have a small piece of
GPLed code included.

Or if you were to make a commercial release from PostgreSQL and in the
process fix some bugs and add some more features, you can keep that stuff
commercially, while under GPL you have to make the source available. That is
you must not improve GPLed code without making these improvements GPL again.

But then this discussion is worthless since we DO have GPLed code in
PostgreSQL. Just check gram.c! If we do not want GPL we cannot use bison at
all. Granted a commercial vendor could work around this by recompiling
gram.c, preproc.c etc.

After all the main function of GPL is to keep free software free, and I have
no problems with that.

Michael
--
Michael Meskes meskes@online-club.de, meskes@debian.org
Go SF49ers! Go Rhein Fire! Use Debian GNU/Linux!