<!--

$PostgreSQL: pgsql/doc/src/sgml/cvs.sgml,v 1.34 2005/08/11 13:52:33 momjian Exp $

$PostgreSQL: pgsql/doc/src/sgml/cvs.sgml,v 1.35 2005/10/15 20:15:48 neilc Exp $

-->

<appendix id="cvs">

</sect1>

</appendix>

<!--

> It became clear that I had a problem with my m3 installation; some

> X11 libraries were not being found correctly.

By the way, you can build the client without the GUI by doing this

in the "client" subdirectory:

m3build -DNOGUI

If you build it that way, then it doesn't need the X11 libraries and

it's quite a bit smaller. The GUI is fun to watch, but it's not

very useful. I originally implemented it because it made debugging

the multi-threaded client program much easier.

To build a statically-linked client, edit <filename>client/src/m3makefile</filename>

to add <literal>build_standalone()</literal>

just before the <literal>program()</literal> entry near

the end of the file:

<programlisting>

build_standalone()

program(cvsup)

</programlisting>

Then, if cvsup has already been built, remove the machine-specific build directory

(e.g. <filename>LINUXELF/</filename>) and rebuild:

<programlisting>

rm -rf LINUXELF

m3build -DNOGUI -v

cp -p LINUXELF/cvsup /usr/local/bin

</programlisting>

> Anyway, with the reinstall and the two-line patch above (and that

> one include-file _POSIX_SOURCE workaround from the previous try),

> things built cleanly.

Good!

> Now I just need a server somewhere to test.

If you want to try it out, there are public servers for the FreeBSD

source repository at cvsup.freebsd.org and cvsup2.freebsd.org.

Here's a suggested supfile:

*default host=cvsup.freebsd.org compress

*default release=cvs

*default base=/home/jdp/cvsup-test# FIX THIS

*default delete use-rel-suffix

# *default tag=.

src-bin

This will fetch you the source repository for the programs that get

installed into "/bin". I chose it because it's one of the smaller

pieces of the system. Make an empty directory someplace for

testing, and change the "FIX THIS" line to specify that directory

after the "base=".

If you are on a T1 or better, you should probably delete the

"compress" keyword in the first line.

As shown, it will get the repository (RCS) files. If you uncomment

the line containing "tag=." then it will instead check out the

latest version of each file. There's a bunch more information about

what you can do in the

<ulink url="http://www.freebsd.org/handbook/cvsup.html">

CVSup Handbook</ulink>.

There is one other thing I want to send you, but not tonight. I

discovered the hard way that you need a malloc package that is

thread-safe with respect to the Modula-3 threads package. The

Modula-3 runtime takes care to do the proper mutual exclusion around

all calls it makes to malloc. But if you call certain functions in

the native C library which in turn call malloc, then the mutual

exclusion gets bypassed. This can lead to rare but baffling core

dumps.

For FreeBSD, I solved this by adding a thread-safe malloc package

into the Modula-3 runtime. The package is quite portable, and I'm

sure it will work well for Linux with very few changes (probably

none at all). I want to send it to you along with instructions

for making it a part of the "libm3core" library. It's very simple,

but I've run out of steam for tonight. :-) Once you have this

malloc in place, the CVSup system should be rock solid. We have

servers that have been up for weeks and have served many thousands

of clients without any observed problems.

> We hope to have the PostgreSQL tree using CVSup within a month or

> so, and hope to retire sup in September...

Great! I'll do my best to help make sure you don't regret it.

John

Tom,

I'm appending the sources for the thread safe version of malloc that

I told you about. I believe that it will simply compile and work

under Linux, but I've never had an opportunity to test it there.

I urge you to put it into your Modula-3 system; otherwise, you

are guaranteed to get occasional mysterious core dumps from cvsupd.

As a first step, I'd suggest simply trying to compile it under

Linux, like this:

cc -O -c malloc.c

You shouldn't get any errors or warnings. If you do, contact me

before you waste any more time on it.

Assuming it compiles OK, copy malloc.c into this directory of your

Modula-3 source tree:

m3/m3core/src/runtime/LINUXELF

In that same directory, edit "m3makefile" and add this line to the

end of the file:

c_source ("malloc")

Then chdir up into "m3/m3core" of the Modula-3 tree and type

"m3build". (I'm assuming you already have a working Modula-3

installation.) After that finishes, become root and type "m3ship"

to install it.

That's all there is to it. If you built cvsup and cvsupd to use

shared libraries, you don't even need to re-link them. They'll pick

up the change automatically from the updated shared library.

Let me know if you run into any problems with it.

By the way, this is a very good malloc in its own right. It's worth

using even aside from the thread safety of it.

Regards,

John

I've deposited a statically built cvsup client executable (and man pages

and test configuration) in

/pub/incoming/cvsup-15.1-client-linux.tar.gz

This was built and linked on Linux/v2.0.30, RH/v4.2, gnulib/v5.3.12 and

includes the thread-safe malloc provided by John Polstra. I'll forward

to you the malloc code and an additional installation e-mail from John.

The Modula-3 installation takes a good bit of room (~50MB?) and the

build environment is unique to Modula-3, but suprisingly enough it

pretty much works.

The cvsup Makefiles do not work on my machine (they are not portable

yet) but each major package (there are 4) can be built without needing

the makefiles with two commands each. Not difficult at all. John gives

some hints in his e-mail on how to build a static executable, and on how

to shrink the size of the executable by leaving out the GUI support.

Again, easy to do.

My client test case, picking up a sub-tree of the FreeBSD distribution,

worked flawlessly. I haven't tried running a server.

Thanks to John for getting me going.

- Tom

For the thread-safe malloc, do the following:

1) install Modula-3

2) add the enclosed file "malloc.c" to m3/m3core/src/runtime/LINUXELF

3) edit the last line of m3makefile in the same directory to add

c_source ("malloc")

4) do an "m3build" and an m3ship from the appropriate directory.

From what John said, the malloc problem can be noticable for the

server-side running cvsupd. Clients may not need it.

Unfortunately I seem to have lost John's original good instructions for

this, so am doing this from memory. May need to ask John to give

instructions again...

- Tom

-->

<!-- Keep this comment at the end of the file

Local variables:

mode:sgml