OSSP CVS Repository

For anyone reporting, please direct new bugs there (¤https://todo.sr.ht/~nabijaczleweli/ossp), you can report without an account by mail at <~nabijaczleweli/ossp@todo.sr.ht>.

For any thawed-out programs, please see if there's any new versions, too (¤https://lists.sr.ht/~nabijaczleweli/ossp).

  libtool: install: ./shtool install -c -m 755 -s .libs/uuid /nix/store/r8clhx2d35c4iy3y299ifx1i8lpaphcx-libossp-uuid-x86_64-w64-mingw32-1.6.2/bin/uuid
  cp: cannot stat '.libs/uuid': No such file or directory

The problem is that the built executable file has a .exe suffix which needs to be accounted for. The following patch fixes this in a cross-platform way:

  diff --git a/Makefile.in b/Makefile.in
  --- a/Makefile.in
  +++ b/Makefile.in
  @@ -56,6 +56,7 @@ CP          = cp
   RMDIR       = rmdir
   SHTOOL      = $(S)/shtool
   LIBTOOL     = $(C)/libtool
  +EXEEXT      = @EXEEXT@
   TRUE        = true
   POD2MAN     = pod2man
   PERL        = @PERL@
  @@ -253,7 +254,7 @@ install:
    -@if [ ".$(WITH_CXX)" = .yes ]; then \
        $(LIBTOOL) --mode=install $(SHTOOL) install -c -m 644 $(CXX_NAME) $(DESTDIR)$(libdir)/; \
    fi
  - @$(LIBTOOL) --mode=install $(SHTOOL) install -c -s -m 755 uuid $(DESTDIR)$(bindir)/
  + @$(LIBTOOL) --mode=install $(SHTOOL) install -c -s -m 755 $(PRG_NAME)$(EXEEXT) $(DESTDIR)$(bindir)/
    $(SHTOOL) install -c -m 644 $(S)/uuid.1 $(DESTDIR)$(mandir)/man1/
    -@if [ ".$(WITH_PERL)" = .yes ]; then \
        (cd $(S)/perl && $(MAKE) $(MFLAGS) install DESTDIR=$(DESTDIR)); \

  --- a/Data/UUID.pm
  +++ b/Data/UUID.pm
  @@ -61,7 +61,7 @@
       my ($self, $nsid, $name) = @_;
       my $uuid = OSSP::uuid->new;
       my $nsiduuid = OSSP::uuid->new;
  -    $nsiduuid->import('bin', $nsiduuid);
  +    $nsiduuid->import('bin', $nsid);
       $uuid = OSSP::uuid->new;
       $uuid->make('v3', $nsiduuid, $name);
       return $uuid->export('bin');

Not sure if fixing this is actually a good idea.

Doing so would mean the code would start generating different UUIDs for the same input. OTOH the current state makes this non-interoperable with other implementations.

  $ perl -MOSSP::uuid -le 'print OSSP::uuid->new->typo'
  unknown contant OSSP::uuid::typo at -e line 1.

TIA && Cheers

I'm trying to use Apache 1.3.26 with php4: 4.2.2-82 and libmm 1.2.1

When trying to start Apache with this combination, following error message is created: PHP Fatal error: Unable to start session mm module in Unknown on line 0

I have checked for the error on google and this seems to be a very widely seen problem. Some people have traced it down to libmm.

See here a very usefull url, describing the potential problem cause: ¤http://garbo.uwasa.fi/pub/linux/SuSE_update/8.0/patches/mm-1118

And here is a quote of the problem from the above link: --start of quote (At initialization, the PHP interpreter tries to get an as large shared memory segment as possible, and MM would try to allocate more than by default is available via /proc/sys/kernel/shmmax. "PHP Fatal error: Unable to start session mm module in Unknown on line 0". In this package the MM internal maximum value is set according to the system default shmmax value again (32MB) --end of quote

Can you fix this problem in the next build of libmm, so that it will be included in new distributions (like SuSE, which I'm using myself)?

It will safe a lot of people a lot of time, trying to find some patch for their current distribution.

Thanks and kind regards, Alex Wulms

The configure script is stopping with checking host system type... Invalid configuration `x86_64-linux-android`: system `android` not recognized

Is there a workaround for this? I would be OK with using a regular C compiler however I chose clang++ because the ndk examples on android are all using it, and I need to gain more experience before attempting to build examples and existing code with regular C.

Thank you.

This simple patch fixes it:

  --- uuid.pc.in  2015-09-12 04:03:34.921192349 +0100
  +++ uuid.pc.in  2015-09-12 04:13:53.226386329 +0100
  @@ -30,5 +30,5 @@
   prefix=@prefix@
  -exec_prefix=${prefix}
  -includedir=${prefix}/include
  -libdir=${exec_prefix}/lib
  +exec_prefix=@exec_prefix@
  +includedir=@includedir@
  +libdir=@libdir@

Generate error from configure:

  ...
  checking for accept in -lsocket... no
  checking for va_copy() function... configure: error: cannot run test program while cross compiling
  See `config.log' for more details.

The problem is AC_CHECK_VA_COPY() from uuid.ac file.

Workaround: ac_cv_va_copy=C99 ./configure --host=arm-linux CC=arm-linux-gnueabihf-gcc CXX=arm-linux-gnueabihf-g++

<mcc.fn.test@lmtp2nntp.invalid> (expanded from <mcc.fn.test@mail2news.mobilcom.de>): host 127.0.0.1[127.0.0.1] said: 550 5.1.1 Recipient did not transform into group. (in reply to RCPT TO command)

Final-Recipient: rfc822; mcc.fn.test@lmtp2nntp.invalid Original-Recipient: rfc822;mcc.fn.test@mail2news.mobilcom.de Action: failed Status: 5.1.1 Remote-MTA: dns; 127.0.0.1 Diagnostic-Code: smtp; 550 5.1.1 Recipient did not transform into group.

I know this piece of code is very old, but there is no alternativ at the market to do the same.

Kind Regards

Bernd

This is due to AC_TRY_RUN(__va_copy_test($2), [ac_cv_va_copy="$1"]) in aclocal.m4. I worked around this problem by defining ac_cv_va_copy=C99 as an environment variable before configure.

It would be nice to have cross compilation working out of the box

On AIX I do encounter this compilation error:

  ./libtool --mode=compile --quiet powerpc-ibm-aix7.1.0.0-gcc -c -I. -O2 -pipe pth_debug.c
  In file included from pth_p.h.in:54,
                   from pth_debug.c:29:
  pth.h:93:2: error: #error "FD_SETSIZE is larger than what GNU Pth can handle."
  Makefile:154: recipe for target 'pth_debug.lo' failed
  make: *** [pth_debug.lo] Error 1

Ok, AIX defines this one:

  $ grep 'define *FD_SETSIZE' /usr/include/sys/*.h
  /usr/include/sys/time.h:#define FD_SETSIZE     65534

Wondering what the relevant configure part was:

  checking for default value of FD_SETSIZE... 1024

And in config.log:

  configure:19255: checking for default value of FD_SETSIZE
  configure:19286: powerpc-ibm-aix7.1.0.0-gcc -o conftest  -O2 -pipe   conftest.c  >&5
  conftest.c: In function 'main':
  conftest.c:53: error: 'fd_set' undeclared (first use in this function)
  conftest.c:53: error: (Each undeclared identifier is reported only once
  conftest.c:53: error: for each function it appears in.)
  conftest.c:56: warning: incompatible implicit declaration of built-in function 'exit'
  configure:19286: $? = 1
  configure: program exited with status 1

Ok, fixing these both problems (error and warning) with this diff:

  --- pth-2.0.7/aclocal.m4
  +++ pth-2.0.7/aclocal.m4
  @@ -1185,7 +1185,9 @@
   changequote(<<, >>)dnl
   <<
   #include <stdio.h>
  +#include <stdlib.h>
   #include <sys/types.h>
  +#include <sys/time.h>
   #include <unistd.h>
   int main(int argc, char *argv[])
   {

After promoting this patch to configure, the relevant line reads:

  checking for default value of FD_SETSIZE... 65534

and the compilation succeeds. Also, 'make test' tells this result now:

  Pth: OK: powerpc-ibm-aix7.1.0.0 | mcsc/sc/mc | down | 2.0.7

Thank you! /haubi/

[philipp@builder ~]$ uuid -v1
639519c8-b019-11e1-9b4b-ff91eac3a44f
[philipp@builder ~]$ uuid -d `uuid -v1`
encode: STR: 6aed0654-b019-11e1-abf4-8f6127f75e13
SIV: 142128870312796779101177586876736298515
decode: variant: DCE 1.1, ISO/IEC 11578:1996
version: 1 (time and node based)
content: time: 2012-06-06 20:51:41.241506.0 UTC
clock: 11252 (usually random)
node: 8f:61:27:f7:5e:13 (local multicast)
[philipp@builder ~]$ ip -0 link show

1. lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   
2. p6p1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000 link/ether 00:22:15:ba:83:bf brd ff:ff:ff:ff:ff:ff
   [philipp@builder ~]$
   

Also, note that when using NetworkManager, eth0 gets renamed as p6p1, so the Linux code won't find "eth0".

Looking at uuid.c:970:

    /*
     *  GENERATE NODE
     */

    if ((mode & UUID_MAKE_MC) || (uuid->mac[0] & BM_OCTET(1,0,0,0,0,0,0,0))) {

what is this code testing for in the right-hand side? Is it testing whether the MAC address was undiscovered? If so, you need to test all 6 octets, i.e.

!memcmp(uuid->mac, "\200\0\0\0\0\0", MAC_LEN)

instead.

If you're testing for a Multicast address, you want:

(uuid->mac[0] & IEEE_MAC_MCBIT)

instead.

bugzilla.redhat.com/show_bug.cgi?id=829532

please note that configure (or configure.ac or one of its include files) needs to detect /usr/include/netpacket/packet.h on linux.

In a nutshell, the strip binary doesn't work when it encounters a file from a different architecture. So when 'install' invokes '/usr/bin/strip' it gets the wrong version of strip when cross-compiling. A cleaner solution is to define STRIP in the makefile and invoke it directly. That way, a cross-compile environment can just override $STRIP.

Thanks!

OS X 10.6.8

Configure (OK):

Golan-Trevize:ossp-uuid-1.6.2 grahamreitz$ ../../source-dir/ossp-uuid/uuid-1.6.2/configure --prefix=/Users/grahamreitz/Development/root/usr/local --without-perl --without-php --without-pgsql Configuring OSSP uuid (Universally Unique Identifier), version 0.1.0 (24-Jun-2011) ... configure: creating ./config.status config.status: creating Makefile config.status: creating uuid-config config.status: creating uuid.pc config.status: creating uuid.h config.status: creating config.h config.status: executing libtool commands config.status: executing adjustment commands

Make (OK):

Golan-Trevize:ossp-uuid-1.6.2 grahamreitz$ make ... gcc -I. -I../../source-dir/ossp-uuid/uuid-1.6.2 -DHAVE_CONFIG_H -O2 -pipe -c ../../source-dir/ossp-uuid/uuid-1.6.2/uuid_cli.c libtool: link: gcc -o .libs/uuid uuid_cli.o ./.libs/libuuid.dylib

Make check (OK):

Make Install (ERROR):

Golan-Trevize:ossp-uuid-1.6.2 grahamreitz$ make install ../../source-dir/ossp-uuid/uuid-1.6.2/shtool mkdir -f -p -m 755 /Users/grahamreitz/Development/root/usr/local ../../source-dir/ossp-uuid/uuid-1.6.2/shtool mkdir -f -p -m 755 /Users/grahamreitz/Development/root/usr/local/bin ../../source-dir/ossp-uuid/uuid-1.6.2/shtool mkdir -f -p -m 755 /Users/grahamreitz/Development/root/usr/local/include ../../source-dir/ossp-uuid/uuid-1.6.2/shtool mkdir -f -p -m 755 /Users/grahamreitz/Development/root/usr/local/lib/pkgconfig ../../source-dir/ossp-uuid/uuid-1.6.2/shtool mkdir -f -p -m 755 /Users/grahamreitz/Development/root/usr/local/share/man/man3 ../../source-dir/ossp-uuid/uuid-1.6.2/shtool mkdir -f -p -m 755 /Users/grahamreitz/Development/root/usr/local/share/man/man1 ../../source-dir/ossp-uuid/uuid-1.6.2/shtool install -c -m 755 uuid-config /Users/grahamreitz/Development/root/usr/local/bin/ ../../source-dir/ossp-uuid/uuid-1.6.2/shtool install -c -m 644 ../../source-dir/ossp-uuid/uuid-1.6.2/uuid-config.1 /Users/grahamreitz/Development/root/usr/local/share/man/man1/ ../../source-dir/ossp-uuid/uuid-1.6.2/shtool install -c -m 644 ../../source-dir/ossp-uuid/uuid-1.6.2/uuid.pc /Users/grahamreitz/Development/root/usr/local/lib/pkgconfig/ cp: ../../source-dir/ossp-uuid/uuid-1.6.2/uuid.pc: No such file or directory make: *** [install] Error 1

Installs without error when installed from the package root directory.

Golan-Trevize:build grahamreitz$ sudo make install ../shtool mkdir -f -p -m 755 /usr/local ../shtool mkdir -f -p -m 755 /usr/local/bin ../shtool mkdir -f -p -m 755 /usr/local/include ../shtool mkdir -f -p -m 755 /usr/local/lib/pkgconfig ../shtool mkdir -f -p -m 755 /usr/local/share/man/man3 ../shtool mkdir -f -p -m 755 /usr/local/share/man/man1 ../shtool install -c -m 755 uuid-config /usr/local/bin/ ../shtool install -c -m 644 ../uuid-config.1 /usr/local/share/man/man1/ ../shtool install -c -m 644 ../uuid.pc /usr/local/lib/pkgconfig/ cp: ../uuid.pc: No such file or directory make: *** [install] Error 1

  *** uuid_dce.c  Fri Mar 18 13:44:57 2011
  --- uuid_dce.c.new      Fri Mar 18 13:56:35 2011
  ***************
  *** 248,254 ****
            LEAVE;
        vp  = str;
        len = UUID_LEN_STR;
  !     if (uuid_export(uuid, UUID_FMT_STR, &vp, &len) != UUID_RC_OK)
            LEAVE;

        /* indicate successful operation */
  --- 248,254 ----
            LEAVE;
        vp  = str;
        len = UUID_LEN_STR;
  !     if (uuid_export(uuid, UUID_FMT_STR, vp, &len) != UUID_RC_OK)
            LEAVE;

        /* indicate successful operation */

Has broken links under the Documentation heading. The report: --- man.cgi: ERROR Can't use an undefined value as filehandle reference (line 104). ---

For example, the first broken link is: ¤http://www.ossp.org/man/man.cgi/pkg/lib/uuid/uuid.pod

--Basil Bourque

  ~/build/uuid-1.6.2$ ~/src/uuid-1.6.2/configure --prefix=$HOME/local
  ... [success]
  ~/build/uuid-1.6.2$ make
  ... [success]
  ~/build/uuid-1.6.2$ make install
  ...
  ~/src/uuid-1.6.2/shtool install -c -m 644 ~/src/uuid-1.6.2/uuid.pc ~/local/lib/pkgconfig/
  cp: cannot stat `~/src/uuid-1.6.2/uuid.pc': No such file or directory
  make: *** [install] Error 1

(I've replaced my $HOME with ~ in the output for brevity.)

The problem appears to be that the install rule is trying to copy uuid.pc from the source tree rather than the build tree (where it can actually be found). Other than that, everything seems to work fine.

If he is correct, please add support for Win64 to ossp-uuid.

If he is incorrect, feel free to close this bug and I'll shoot this back to the PostgreSQL/EnterpriseDB folks.

See: ¤http://archives.postgresql.org/pgsql-general/2010-09/msg01088.php

Compounding this problem, both projects install uuid.pc, so if you do a pkg-config check for "uuid", it's anyone's guess which API you'll end up with.

¤https://bugs.freedesktop.org/show_bug.cgi?id=22972 has more on this.

It would be very useful if you could add a header with a namespaced name (/usr/include/ossp-uuid.h would work, for instance), move the uuid declarations there, and make your uuid.h just #include "ossp-uuid.h" for backwards compatibility. Similarly, it'd be great if you could provide ossp-uuid.pc (which is what the Debian package calls it already) in addition to uuid.pc.

I've filed a very similar feature request on e2fsprogs.

At ¤http://www.ossp.org/pkg/lib/mm/ the manuals are not available, the server reports an error.

        man.cgi: ERROR

        Can't use an undefined value as filehandle reference (line 104).

My hacky solution to this problem was to add the following code to uuid.h.in, before compiling and installing ossp-uuid.

  /*
     OS X ships with 'int uuid_compare(uuid_t uu1, uuid_t uu2)' in the c library.
     This will always be picked up when linking. So use a non conflicting name.
  */

  #ifdef __APPLE__
  #define uuid_compare ossp_uuid_compare
  #endif

Maybe there's a better way to solve this?

Mac ports work around it with this patch: ¤http://trac.macports.org/browser/trunk/dports/devel/ossp-uuid/files/patch-Makefile.in.diff

This is probably the same issue as ticket #122

...
./libtool --quiet --mode=compile /opt/studio/SOS11/SUNWspro/bin/cc -c -xO3 -xarch=v9 -I/opt/csw/include mm_vers.c
./libtool --quiet --mode=link /opt/studio/SOS11/SUNWspro/bin/cc -o libmm.la mm_global.lo mm_alloc.lo mm_core.lo mm_lib.lo mm_vers.lo \
            -rpath /opt/csw/lib/64 -version-info `./shtool version -l c -d libtool mm_vers.c`
./libtool --quiet --mode=compile /opt/studio/SOS11/SUNWspro/bin/cc -c -xO3 -xarch=v9 -I/opt/csw/include mm_test.c
./libtool --quiet --mode=link /opt/studio/SOS11/SUNWspro/bin/cc -o mm_test mm_test.lo libmm.la
ld: fatal: file .libs/mm_test.o: wrong ELF class: ELFCLASS64
ld: fatal: File processing errors. No output written to .libs/mm_test
gmake[2]: *** [mm_test] Error 1

This is because the CFLAGS turning on 64 bit are not passed to libtool.

I fixed this by changing the following code from around line 857 of str_format.c:

                case 's':
                    s = va_arg(ap, char *);
                    if (s != NULL) {
                        s_len = str_len(s);
                        if (adjust_precision && precision < s_len)
                            s_len = precision;
                    }
                    else {
                        s = S_NULL;
                        s_len = S_NULL_LEN;
                    }
                    pad_char = ' ';
                    break;

to:

                case 's':
                    s = va_arg(ap, char *);
                    if (s != NULL) {
                        const char *p = s;
                        int maxlen = adjust_precision ? precision : INT_MAX;
                        s_len = 0;
                        while (*p++ != 0 && maxlen-- > 0)
                            s_len++;
                        if (adjust_precision && precision < s_len)
                            s_len = precision;
                    }
                    else {
                        s = (char *) S_NULL;
                        s_len = S_NULL_LEN;
                    }
                    pad_char = ' ';
                    break;

(There are probably better fixes.)

Hope that's helpful,

Joseph Heenan

while (*p++ != 0 && maxlen-- > 0)

to:

while (maxlen-- > 0 && *p++ != 0)

It appears this code could be at fault:

                /* Unsigned Hexadecimal Integer */
                case 'x':
                case 'X':
                    if (var_type == IS_QUAD) {
                        ui_quad = va_arg(ap, u_quad_int);
                        s = conv_p2_quad(ui_quad, 4, *fmt,
                                         &num_buf[NUM_BUF_SIZE], &s_len);
                    }
                    else {
                        if (var_type == IS_LONG)
                            ui_num = (u_long_int)va_arg(ap, u_long_int);
                        else if (var_type == IS_SHORT)
                            ui_num = (u_long_int)(unsigned short)va_arg(ap, unsigned int);
                        else
                            ui_num = (u_long_int)va_arg(ap, unsigned int);
                        s = conv_p2(ui_num, 4, *fmt, &num_buf[NUM_BUF_SIZE], &s_len);
                    }
                    FIX_PRECISION(adjust_precision, precision, s, s_len);
                    if (alternate_form && i_num != 0) {
                        *--s = *fmt; /* 'x' or 'X' */
                        *--s = '0';
                        s_len += 2;
                    }
                    break;

I think the:

                    if (alternate_form && i_num != 0) {

should be:

                    if (alternate_form && ui_num != 0) {

udev Linux distros link the MAC addresses with the device names, so that removable devices don't randomly change configuration, and fixed hardware doesn't depend on driver load order. This can result in a machine that has eth2, but not eth[01], for example.

This appears to affect programs that use the library as well, and not just the CLI, but that's where I discovered it so I'm reporting it as such.

Steps to reproduce: Set up a udev Linux distro (Ubuntu, Debian, etc.), then change the ethernet hardware, and run uuid.

Expected behaviour: uuid should use the new MAC address.

Actual behaviour: uuid does not identify the new ethernet address and silently used random multicast MAC addresses.

Workaround: Reconfigure udev to make the new device eth0.

Suggested fixes: 1. Discover device names, or iterate through potential ones. 2. Emit a warning if uuid expected to use a hardware address but couldn't. 3. Allow a MAC address to be specified. 4. Allow an ethernet device to be specified, either on the command line or through an environment variable.

When installing the package, a message is generated and no files are installed. The message is "make: `install' is up to date."

A.

Details here:

  http://archives.postgresql.org/pgsql-bugs/2008-01/msg00255.php

Thanks,

David

A better solution would be to return an std::string. Though this may break some existing user's compatibility, it will make uuid much nicer to use, rather than:

char *sid = id.string(); printf("%s\n", sid); free(sid);

I could just do:

printf("%s\n", id.string().c_str());

I'm trying to build with gcc-4.1.2 and glibc-2.5. Any hint on how to get it to compile would be appreciated.

It fails on:

./libtool --mode=compile --quiet arm-angstrom-linux-gnueabi-gcc -march=armv4t -mtune=arm920t -c -isystem/home/moko/build/tmp/staging/arm-angstrom-linux-gnueabi/usr/include -I. -isystem/home/moko/build/tmp/staging/arm-angstrom-linux-gnueabi/usr/include -fexpensive-optimizations -fomit-frame-pointer -frename-registers -Os -I/home/moko/build/tmp/work/armv4t-angstrom-linux-gnueabi/pth-2.0.7-r0/pth-2.0.7 -pipe pth_mctx.c pth_mctx.c:480:2: error: #error "Unsupported Linux (g)libc version and/or platform" make: *** [pth_mctx.lo] Error 1

An example that first shows the table definition, then the failing statement followed by the explicit insert statement that tries the same with DEFAULT and finally the explicit insert that works:

  simon=# \d bar
      Table "public.bar"
   Column | Type | Modifiers
  --------+------+-----------
   foo    | uuid |
   data   | text | not null
  Foreign-key constraints:
      "bar_foo_fkey" FOREIGN KEY (foo) REFERENCES foo(id)

  simon=# insert into bar (data) values ('bla');
  ERROR:  invalid UUID string length 7 (expected 36)
  simon=# insert into bar (foo, data) values (DEFAULT, 'bar');
  ERROR:  invalid UUID string length 7 (expected 36)
  simon=# insert into bar (foo, data) values (NULL, 'bla');
  INSERT 0 1

No idea or patch on how to solve it yet, but at least i wanted to file a ticket so others have a chance to come up with a possible fix.

  uuid.c: In function 'pg_uuid_send':
  uuid.c:203: error: 'struct varlena' has no member named 'vl_len'
  make[1]: *** [uuid.o] Error 1
  make: *** [pgsql/libuuid.so] Error 2

See the attached log for additional details.

Thanks,

Jörg Beyer

I tried to install ossp uuid 1.6.0 on my OS X-machine.

'make check' failed when checking the Perl bindings. See the attached log for additional details.

Any help is highly appreciated -- I need uuid for beta testing the upcoming PostgreSQL 8.3 release...

Thanks,

Jörg Beyer

Further investigation (especially a close look at the log and the build directory) brought to light that ossp-uuid's 'make check' tried to load a library that couldn't be in place at first pass -- simply because it didn't exist and had yet to be installed. By ossp-uuid itself. That's what I'd call a circular reference ;-) (Nothing wrong with OS X or its DynaLoader, btw.)

Bottom line: run [sudo] make install, then run make check again, and you will see that everything is fine, at least so far.

Hope this helps, cheers Jörg Beyer

1. There's a bug in the function js_FreeRuntimeScriptState at jsscript.c:994. If you create a runtime and then destroy it before creating any contexts, the statement:

JS_REMOVE_LINK(&sfp->links);

causes a segfault because sfp is NULL. I didn't have the time or inclination to investigate this, but adding:

if(! sfp) break;

before that statement eliminated the crash.

According to the SpiderMonkey team:

"I don't know what version OSSP is using, but this sounds like bug 345350 (¤https://bugzilla.mozilla.org/show_bug.cgi?id=345350). Your patch just detects this in the loop, but that adds an if test to every iteration that runs when the table has not been finished. The patch in bug 345350 tests before the loop."

2. I had to build a Visual Studio solution for js since I need to deploy on Windows as well as UNIX (and mingw/cygwin were not an option). I ran into the following portability problems:

a. prjmtime.c fails to compile because the two #include statements at line 61 are not sufficient; I got lots of errors about LPCONTEXT and such being undefined. I replaced these with a single "#include <windows.h >" to solve the problem.

b. I copied config.h.in to config.h and added the following at the bottom:

#define __VA_COPY_USE __VA_COPY_USE_CPP

But this caused compiler errors because the #define of that macro has a typo: one of the close parens is in the wrong place. It should be: #define __VA_COPY_USE_CPP(d, s) memcpy((void *)(d), (void *)(s), sizeof(*(s)))

It looks like __VA_COPY_USE_CPS has the same problem.

c. The following macros have to be defined globally for the project to eliminate the hundreds of VC++ compiler warnings I got. This should be documented in a README or somewhere:

XP_WIN

OSSP

EXPORT_JS_API

_CRT_SECURE_NO_DEPRECATE

_USE_32BIT_TIME_T

Also I had to turn off the "Detect 64-bit Portability Issues" option (no /Wp64 switch to the compiler).

I will happily contribute my Visual Studio 2005 Solution and Project files if you're willing to add them to the OSSP js distro (it's just 3 small XML files).

The applied patch fixes this.

Greetings, Frank

*** pthread_ex.c.manPage	2007-06-15 14:56:55.000000000 +0200
--- pthread_ex.c	2007-06-15 14:57:45.000000000 +0200
***************
*** 1,5 ****
--- 1,6 ----
  #include <stdlib.h>
  #include <pthread.h>
+ #include <errno.h>

  #define PTHREAD_EX_INTERNAL
  #include "pthread_ex.h"
*************** static void *pthread_create_wrapper(void
*** 62,69 ****
      EX_CTX_INITIALIZE(ex_ctx);
      pthread_setspecific(pthread_ex_ctx_key, ex_ctx);

!     /* perform original operation */
!     return wrapper->entry(wrapper->arg);
  }

  /* pthread_create() wrapper */
--- 63,73 ----
      EX_CTX_INITIALIZE(ex_ctx);
      pthread_setspecific(pthread_ex_ctx_key, ex_ctx);

!     /* perform original operation, but free wrapper first */
!     void *(*wentry)(void *) = wrapper->entry;
!     void *warg = wrapper->arg;
!     free(wrapper);
!     return wentry(warg);
  }

  /* pthread_create() wrapper */
*************** int pthread_create_ex(pthread_t *thread,
*** 71,81 ****
                        const pthread_attr_t *attr,
                        void *(*entry)(void *), void *arg)
  {
!     pthread_create_ex_t wrapper;

      /* spawn thread but execute start
         function through wrapper */
!     wrapper.entry = entry;
!     wrapper.arg   = arg;
!     return pthread_create(thread, attr, pthread_create_wrapper, &wrapper);
  }
--- 75,86 ----
                        const pthread_attr_t *attr,
                        void *(*entry)(void *), void *arg)
  {
!     pthread_create_ex_t* wrapper = (pthread_create_ex_t*)malloc(sizeof(pthread_create_ex_t));
!     if (wrapper == NULL) return ENOMEM;

      /* spawn thread but execute start
         function through wrapper */
!     wrapper->entry = entry;
!     wrapper->arg   = arg;
!     return pthread_create(thread, attr, pthread_create_wrapper, wrapper);
  }

Here's a trivial patch that installs and also deinstalles in the same manner as done right now. I've just made it use PostgreSQLs $(docdir) variable so it should fit everywhere.

Regards, Simon

	--- pgsql/Makefile.orig	Mon Nov 20 20:26:27 2006
	+++ pgsql/Makefile	Fri Jun  8 16:38:50 2007
	@@ -42,10 +42,12 @@ install: all
	 	$(mkinstalldirs) $(DESTDIR)$(datadir)
	 	$(INSTALL_SHLIB) $(shlib) $(DESTDIR)$(pkglibdir)/uuid$(DLSUFFIX)
	 	$(INSTALL_DATA) uuid.sql $(DESTDIR)$(datadir)/uuid.sql
	+	$(INSTALL_DATA) uuid.txt $(DESTDIR)$(docdir)/uuid.txt

	 uninstall:
	 	-rm -f $(DESTDIR)$(pkglibdir)/uuid$(DLSUFFIX)
	 	-rm -f $(DESTDIR)$(datadir)/uuid.sql
	+	-rm -f $(DESTDIR)$(docdir)/uuid.txt

	 clean distclean: clean-lib
	 	rm -f $(OBJS)

Very simple patch to fix it... Regards, Simon

	--- uuid.ts	Mon Jan  1 19:13:20 2007
	+++ /tmp/uuid.ts	Fri Jun  8 16:13:59 2007
	@@ -89,7 +89,7 @@
	     and $len == UUID_LEN_STR), "uuid_export (5)");
	 $rc = uuid_export($uuid_ns, UUID_FMT_SIV, $ptr, $len);
	 ok((    $rc == UUID_RC_OK
	-    and $ptr eq "3789866285607910888100818383505376205"
	+    and $ptr == "3789866285607910888100818383505376205"
	     and $len <= UUID_LEN_SIV), "uuid_export (6)");

	 $rc = uuid_destroy($uuid_ns);

The following patch allows the pth_scheduler_load() macro to detect a discontinuity in the time, either backwards, or forwards by more than 10 seconds. Upon detection of the discontinuity, the load average value is reset to the current load.

  --- pth-2.0.7.orig/pth_sched.c	2006-06-08 10:54:03.000000000 -0700
  +++ pth-2.0.7/pth_sched.c	2007-03-27 15:55:23.000000000 -0700
  @@ -137,20 +137,31 @@
    * been occurred and we would have been given more chances to operate).
    * The actual average load is calculated through an exponential average
    * formula.
  + *
  + * If the system clock is adjusted forward by more than 10 seconds,
  + * or if the system clock is adjusted backwards, the load average is
  + * reset to the current load.
    */
  -#define pth_scheduler_load(now) \
  -    if (pth_time_cmp((now), &pth_loadticknext) >= 0) { \
  -        pth_time_t ttmp; \
  -        int numready; \
  -        numready = pth_pqueue_elements(&pth_RQ); \
  +
  +#define pth_scheduler_load(now) { \
  +    pth_time_t ttmp; \
  +    pth_time_t ten_sec = PTH_TIME(10,0); \
  +    int numready; \
  +    numready = pth_pqueue_elements(&pth_RQ); \
  +    pth_time_set(&ttmp, (now)); \
  +    pth_time_sub(&ttmp, &pth_loadticknext); \
  +    if ((pth_time_cmp(&ttmp, &ten_sec) >= 0) || !pth_time_pos(&ttmp)) { \
  +         pth_loadval = numready; \
  +    } else { \
           pth_time_set(&ttmp, (now)); \
           do { \
               pth_loadval = (numready*0.25) + (pth_loadval*0.75); \
               pth_time_sub(&ttmp, &pth_loadtickgap); \
           } while (pth_time_cmp(&ttmp, &pth_loadticknext) >= 0); \
  -        pth_time_set(&pth_loadticknext, (now)); \
  -        pth_time_add(&pth_loadticknext, &pth_loadtickgap); \
  -    }
  +    } \
  +    pth_time_set(&pth_loadticknext, (now)); \
  +    pth_time_add(&pth_loadticknext, &pth_loadtickgap); \
  +}

   /* the heart of this library: the thread scheduler */
   intern void *pth_scheduler(void *dummy)
  }

  --- pth-2.0.7.orig/pth_sched.c	2006-06-08 10:54:03.000000000 -0700
  +++ pth-2.0.7/pth_sched.c	2007-03-28 10:43:30.000000000 -0700
  @@ -137,12 +137,25 @@
    * been occurred and we would have been given more chances to operate).
    * The actual average load is calculated through an exponential average
    * formula.
  + *
  + * If the system clock is adjusted forward by more than 10 seconds,
  + * or if the system clock is adjusted backwards, the load average is
  + * reset to the current load.
    */
  -#define pth_scheduler_load(now) \
  -    if (pth_time_cmp((now), &pth_loadticknext) >= 0) { \
  -        pth_time_t ttmp; \
  -        int numready; \
  -        numready = pth_pqueue_elements(&pth_RQ); \
  +
  +#define pth_scheduler_load(now) { \
  +    pth_time_t ttmp; \
  +    pth_time_t ten_sec = PTH_TIME(10,0); \
  +    int numready; \
  +    numready = pth_pqueue_elements(&pth_RQ); \
  +    pth_time_set(&ttmp, (now)); \
  +    pth_time_add(&ttmp, &pth_loadtickgap); \
  +    pth_time_sub(&ttmp, &pth_loadticknext); \
  +    if ((pth_time_cmp(&ttmp, &ten_sec) >= 0) || !pth_time_pos(&ttmp)) { \
  +         pth_loadval = numready; \
  +        pth_time_set(&pth_loadticknext, (now)); \
  +        pth_time_add(&pth_loadticknext, &pth_loadtickgap); \
  +    } else if (pth_time_cmp((now), &pth_loadticknext) >= 0) { \
           pth_time_set(&ttmp, (now)); \
           do { \
               pth_loadval = (numready*0.25) + (pth_loadval*0.75); \
  @@ -150,7 +163,8 @@
           } while (pth_time_cmp(&ttmp, &pth_loadticknext) >= 0); \
           pth_time_set(&pth_loadticknext, (now)); \
           pth_time_add(&pth_loadticknext, &pth_loadtickgap); \
  -    }
  +    } \
  +}

   /* the heart of this library: the thread scheduler */
   intern void *pth_scheduler(void *dummy)

postfix (I assume beginning with 2.3.x) generates "RCPT TO" envelope addresses extended by the "ORCPT" original recipient component. E.g. RCPT TO:<newsgroup@lmtp2nntp.invalid> ORCPT=rfc822;newsgroup@lmtp2nntp.invalid

The additional component might lead to problems if lmtp2nntp runs in groupmode envelope since the parsing of the envelope address will give an unexpected result. For me, the following patch (lmtp2nntp-1.4.1) works, but this is not a thorough parsing at all:

--- lmtp2nntp_main.c    2004-05-07 16:52:03.000000000 +0200
+++ lmtp2nntp_main.c    2007-02-07 20:05:00.000000000 +0100
@@ -1315,7 +1315,7 @@
      *  RFC1893 3.5 Network and Routing Status          X.5.2   Syntax error
      */
     logbook(ctx->l2, L2_LEVEL_TRACE, "checking parameter syntax");
-    if (str_parse(req->msg, "m/^RCPT To:\\s*(.+)$/i", &cp) <= 0) {
+    if (str_parse(req->msg, "m/^RCPT To:\\s*(\\S+)/i", &cp) <= 0) {
         res.statuscode = "501";
         res.dsncode    = "5.5.2";
         res.statusmsg  = "Syntax error in parameters.";=

1. On line 250:

  len = UUID_LEN_STR

should be:

  len = UUID_LEN_STR + 1

as this is later checked in the function below uuid_export().

2. On line 251: third parameter to uuid_export should be 'vp' and not '&vp'. The uuid_to_string function already receives a pointer to a char array in 'str'. The functions below uuid_export() do not expect another level of indirection.

#make WITH_PERL=yes

.....

configure: creating ./config.status

config.status: creating Makefile

config.status: WARNING: Makefile.in seems to ignore the --datarootdir setting config.status: creating uuid-config

config.status: WARNING: uuid-config.in seems to ignore the --datarootdir setting

config.status: creating uuid.pc

config.status: creating uuid.h

config.status: creating config.h

config.status: executing adjustment commands

===> Building for ossp-uuid-1.5.1

cc -I. -I. -DHAVE_CONFIG_H -O2 -pipe -march=pentium4 -c ./uuid.c -o uuid.o

cc -I. -I. -DHAVE_CONFIG_H -O2 -pipe -march=pentium4 -c ./uuid_md5.c -o uuid_md5.o

cc -I. -I. -DHAVE_CONFIG_H -O2 -pipe -march=pentium4 -c ./uuid_sha1.c -o uuid_sha1.o

cc -I. -I. -DHAVE_CONFIG_H -O2 -pipe -march=pentium4 -c ./uuid_prng.c -o uuid_prng.o

cc -I. -I. -DHAVE_CONFIG_H -O2 -pipe -march=pentium4 -c ./uuid_mac.c -o uuid_mac.o

cc -I. -I. -DHAVE_CONFIG_H -O2 -pipe -march=pentium4 -c ./uuid_ui64.c -o uuid_ui64.o

cc -I. -I. -DHAVE_CONFIG_H -O2 -pipe -march=pentium4 -c uuid_ui128.c -o uuid_ui128.o

cc -I. -I. -DHAVE_CONFIG_H -O2 -pipe -march=pentium4 -c ./uuid_str.c -o uuid_str.o

mkdir .libs

libtool: link: warning: `-rpath' is ignored for archives

libtool: link: warning: `-version-info/-version-number' is ignored for archives ar cru libuuid.a uuid.o uuid_md5.o uuid_sha1.o uuid_prng.o uuid_mac.o uuid_ui64.o uuid_ui128.o uuid_str.o ranlib libuuid.a cc -I. -I. -DHAVE_CONFIG_H -O2 -pipe -march=pentium4 -c ./uuid_cli.c cc -o uuid uuid_cli.o libuuid.a

no source directory found (where libuuid.la is located) at Makefile.PL line 37.

*** Error code 2

Stop in /usr/ports/misc/ossp-uuid/work/uuid-1.5.1.

*** Error code 1

Stop in /usr/ports/misc/ossp-uuid.

#perl -v This is perl, v5.8.8 built for i386-freebsd-64int

#uname -a FreeBSD dst10 6.1-RELEASE-p6 FreeBSD 6.1-RELEASE-p6

#make mkdir .libs gcc -I. -I. -DHAVE_CONFIG_H -O2 -pipe -c ./uuid.c -fPIC -DPIC -o .libs/uuid.o gcc -I. -I. -DHAVE_CONFIG_H -O2 -pipe -c ./uuid.c -o uuid.o >/dev/null 2>&1 gcc -I. -I. -DHAVE_CONFIG_H -O2 -pipe -c ./uuid_md5.c -fPIC -DPIC -o .libs/uuid_md5.o gcc -I. -I. -DHAVE_CONFIG_H -O2 -pipe -c ./uuid_md5.c -o uuid_md5.o >/dev/null 2>&1 gcc -I. -I. -DHAVE_CONFIG_H -O2 -pipe -c ./uuid_sha1.c -fPIC -DPIC -o .libs/uuid_sha1.o gcc -I. -I. -DHAVE_CONFIG_H -O2 -pipe -c ./uuid_sha1.c -o uuid_sha1.o >/dev/null 2>&1 gcc -I. -I. -DHAVE_CONFIG_H -O2 -pipe -c ./uuid_prng.c -fPIC -DPIC -o .libs/uuid_prng.o gcc -I. -I. -DHAVE_CONFIG_H -O2 -pipe -c ./uuid_prng.c -o uuid_prng.o >/dev/null 2>&1 gcc -I. -I. -DHAVE_CONFIG_H -O2 -pipe -c ./uuid_mac.c -fPIC -DPIC -o .libs/uuid_mac.o gcc -I. -I. -DHAVE_CONFIG_H -O2 -pipe -c ./uuid_mac.c -o uuid_mac.o >/dev/null 2>&1 gcc -I. -I. -DHAVE_CONFIG_H -O2 -pipe -c ./uuid_ui64.c -fPIC -DPIC -o .libs/uuid_ui64.o gcc -I. -I. -DHAVE_CONFIG_H -O2 -pipe -c ./uuid_ui64.c -o uuid_ui64.o >/dev/null 2>&1 gcc -I. -I. -DHAVE_CONFIG_H -O2 -pipe -c uuid_ui128.c -fPIC -DPIC -o .libs/uuid_ui128.o gcc -I. -I. -DHAVE_CONFIG_H -O2 -pipe -c uuid_ui128.c -o uuid_ui128.o >/dev/null 2>&1 gcc -I. -I. -DHAVE_CONFIG_H -O2 -pipe -c ./uuid_str.c -fPIC -DPIC -o .libs/uuid_str.o gcc -I. -I. -DHAVE_CONFIG_H -O2 -pipe -c ./uuid_str.c -o uuid_str.o >/dev/null 2>&1 gcc -shared .libs/uuid.o .libs/uuid_md5.o .libs/uuid_sha1.o .libs/uuid_prng.o .libs/uuid_mac.o .libs/uuid_ui64.o .libs/uuid_u i128.o .libs/uuid_str.o -Wl,-soname -Wl,libuuid.so.15 -o .libs/libuuid.so.15 (cd .libs && rm -f libuuid.so && ln -s libuuid.so.15 libuuid.so) (cd .libs && rm -f libuuid.so && ln -s libuuid.so.15 libuuid.so) ar cru .libs/libuuid.a uuid.o uuid_md5.o uuid_sha1.o uuid_prng.o uuid_mac.o uuid_ui64.o uuid_ui128.o uuid_str.o ranlib .libs/libuuid.a creating libuuid.la (cd .libs && rm -f libuuid.la && ln -s ../libuuid.la libuuid.la) gcc -I. -I. -DHAVE_CONFIG_H -O2 -pipe -c ./uuid_cli.c gcc -o .libs/uuid uuid_cli.o ./.libs/libuuid.so -Wl,--rpath -Wl,/usr/local/lib creating uuid Checking if your kit is complete... Looks good Writing Makefile for OSSP::uuid cp uuid.pod blib/lib/OSSP/uuid.pod cp uuid.pm blib/lib/OSSP/uuid.pm /usr/bin/perl /usr/local/lib/perl5/5.8.8/ExtUtils/xsubpp -typemap /usr/local/lib/perl5/5.8.8/ExtUtils/typemap -typemap uuid.t m uuid.xs > uuid.xsc && mv uuid.xsc uuid.c cc -c -I. -I.. -DAPPLLIB_EXP="/usr/local/lib/perl5/5.8.8/BSDPAN" -DHAS_FPSETMASK -DHAS_FLOATINGPOINT_H -fno-strict-aliasing -pipe -Wdeclaration-after-statement -I/usr/local/include -O2 -pipe -march=pentium4 -DVERSION=\"1.0501\" -DXS_VERSION=\"1.0 501\" -DPIC -fPIC "-I/usr/local/lib/perl5/5.8.8/mach/CORE" uuid.c Running Mkbootstrap for OSSP::uuid () chmod 644 uuid.bs rm -f blib/arch/auto/OSSP/uuid/uuid.so LD_RUN_PATH="/usr/home/alexvs/uuid-1.5.1/perl/../.libs" cc -shared -L/usr/local/lib -Wl,-Bsymbolic uuid.o -o blib/arch/auto /OSSP/uuid/uuid.so -L/usr/home/alexvs/uuid-1.5.1/perl/../.libs -L/usr/home/alexvs/uuid-1.5.1/perl/.. -luuid chmod 755 blib/arch/auto/OSSP/uuid/uuid.so cp uuid.bs blib/arch/auto/OSSP/uuid/uuid.bs chmod 644 blib/arch/auto/OSSP/uuid/uuid.bs Manifying blib/man3/OSSP::uuid.3 Warning: -L../.libs changed to -L/usr/home/alexvs/uuid-1.5.1/perl/../.libs Warning: -L.. changed to -L/usr/home/alexvs/uuid-1.5.1/perl/..

#make check ==== UUID version 1 (time and node based): 4 single iterations 4717f0ee-7240-11db-b1bf-00167647fabf 4717f440-7240-11db-add1-00167647fabf 4717f530-7240-11db-aa32-00167647fabf 4717f60c-7240-11db-aad3-00167647fabf ==== UUID version 1 (time and node based): 4 subsequent iterations 47210d82-7240-11db-9367-00167647fabf 472110d4-7240-11db-9368-00167647fabf 4721119c-7240-11db-9369-00167647fabf 47211246-7240-11db-936a-00167647fabf ==== UUID version 3 (name based, MD5): 2 times repeated 02d9e6d5-9467-382e-8f9b-9300a64ac3cd 02d9e6d5-9467-382e-8f9b-9300a64ac3cd ==== UUID version 5 (name based, SHA-1): 2 times repeated 8f4ca4fd-154e-5063-b6db-aa91af137037 8f4ca4fd-154e-5063-b6db-aa91af137037 ==== UUID version 4 (random data based): 4 single iterations 2be24da0-ee73-4bc5-b5ba-c26f0bbbdb95 cc0a2811-835d-4b65-ba67-e00bedf0f75b 10fecc0a-0cea-41ed-a16b-112616ea99b1 0e00ae23-7766-42dd-babd-c6e9cb5b3799 ==== UUID version 4 (random data based): 4 subsequent iterations 3d3224bb-c8ed-42d9-9814-890f7239f219 3e19ea08-8925-4bf0-a45f-29caa0ef56e2 255d6d9c-c9fd-4506-a880-ef0e09776c80 2c65f7a7-e314-4563-8bd8-86d3aea4f9f9 ==== UUID version 1 generation and decoding encode: STR: 4751335e-7240-11db-be68-00167647fabf SIV: 94796805631966157295996677974942808767 decode: variant: DCE 1.1, ISO/IEC 11578:1996 version: 1 (time and node based) content: time: 2006-11-12 11:23:53.753891.0 UTC clock: 15976 (usually random) node: 00:16:76:47:fa:bf (global unicast) encode: STR: 475ff290-7240-11db-b92a-47c26816a9a9 SIV: 94873375689628068064686297910821169577 decode: variant: DCE 1.1, ISO/IEC 11578:1996 version: 1 (time and node based) content: time: 2006-11-12 11:23:53.850536.0 UTC clock: 14634 (usually random) node: 47:c2:68:16:a9:a9 (local multicast) ==== UUID version 3 generation and decoding encode: STR: 02d9e6d5-9467-382e-8f9b-9300a64ac3cd SIV: 3789866285607910888100818383505376205 decode: variant: DCE 1.1, ISO/IEC 11578:1996 version: 3 (name based, MD5) content: 02:D9:E6:D5:94:67:08:2E:0F:9B:93:00:A6:4A:C3:CD (not decipherable: MD5 message digest only) ==== UUID version 5 generation and decoding encode: STR: 8f4ca4fd-154e-5063-b6db-aa91af137037 SIV: 190477564324985592756740458922137317431 decode: variant: DCE 1.1, ISO/IEC 11578:1996 version: 5 (name based, SHA-1) content: 8F:4C:A4:FD:15:4E:00:63:36:DB:AA:91:AF:13:70:37 (not decipherable: truncated SHA-1 message digest only) ==== UUID version 3 generation and decoding encode: STR: 95693357-fc2b-4b95-af6a-d871748ef5e5 SIV: 198601203915881110163765567909717276133 decode: variant: DCE 1.1, ISO/IEC 11578:1996 version: 4 (random data based) content: 95:69:33:57:FC:2B:0B:95:2F:6A:D8:71:74:8E:F5:E5 (no semantics: random data only) ==== Perl bindings to C API PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" uuid.ts uuid....dubious Test returned status 0 (wstat 139, 0x8b) DIED. FAILED tests 4-36 Failed 33/36 tests, 8.33% okay Failed Test Stat Wstat Total Fail Failed List of Failed

Stop in /usr/home/alexvs/uuid-1.5.1/perl. *** Error code 1 (ignored)

#perl -v This is perl, v5.8.8 built for i386-freebsd-64int

#uname -a FreeBSD dst10 6.1-RELEASE-p6 FreeBSD 6.1-RELEASE-p6

fetch ¤ftp://ftp.ossp.org/pkg/lib/uuid/uuid-1.5.1.tar.gz gzip -d uuid-1.5.1.tar.gz tar -xjf uuid-1.5.1.tar cd uuid-1.5.1 ./configure --with-perl make make check ......... ==== Perl bindings to C API PERL_DL_NONLAZY=1 /usr/bin/perl "-MExtUtils::Command::MM" "-e" "test_harness(0, 'blib/lib', 'blib/arch')" uuid.ts uuid....dubious Test returned status 0 (wstat 139, 0x8b) DIED. FAILED tests 4-36 Failed 33/36 tests, 8.33% okay Failed Test Stat Wstat Total Fail Failed List of Failed

Stop in /usr/ports/misc/ossp-uuid/uuid-1.5.1/perl. *** Error code 1 (ignored)

perl -V Summary of my perl5 (revision 5 version 8 subversion 8) configuration: Platform: osname=freebsd, osvers=6.1-release, archname=i386-freebsd-64int

In uuid_md5.h on line 57 the struct md5_st is defined. But only the name is defined the struct itself is missing. Most probably causing the error messages.

cc -I. -I. -DHAVE_CONFIG_H -c uuid.c -DPIC -o .libs/uuid.o "uuid_md5.h", line 57.16: 1506-166 (S) Definition of function md5_st requires parentheses. "uuid_md5.h", line 57.23: 1506-276 (S) Syntax error: possible missing '{'? "uuid_md5.h", line 63.5: 1506-045 (S) Undeclared identifier MD5_RC_OK. "uuid_md5.h", line 64.5: 1506-045 (S) Undeclared identifier MD5_RC_ARG. "uuid_md5.h", line 65.5: 1506-045 (S) Undeclared identifier MD5_RC_MEM. "uuid_md5.h", line 66.1: 1506-277 (S) Syntax error: possible missing ';' or ','? "uuid_md5.h", line 66.3: 1506-273 (E) Missing type in declaration of md5_rc_t. "uuid_md5.h", line 68.8: 1506-166 (S) Definition of function md5_rc_t requires parentheses. "uuid_sha1.h", line 63.5: 1506-045 (S) Undeclared identifier SHA1_RC_OK. "uuid_sha1.h", line 64.5: 1506-045 (S) Undeclared identifier SHA1_RC_ARG. "uuid_sha1.h", line 65.5: 1506-045 (S) Undeclared identifier SHA1_RC_MEM. "uuid_sha1.h", line 66.1: 1506-277 (S) Syntax error: possible missing ';' or ','? "uuid_sha1.h", line 66.3: 1506-273 (E) Missing type in declaration of sha1_rc_t. "uuid_sha1.h", line 68.8: 1506-166 (S) Definition of function sha1_rc_t requires parentheses. "uuid_prng.h", line 57.5: 1506-045 (S) Undeclared identifier PRNG_RC_OK. "uuid_prng.h", line 58.5: 1506-045 (S) Undeclared identifier PRNG_RC_ARG. "uuid_prng.h", line 59.5: 1506-045 (S) Undeclared identifier PRNG_RC_MEM. "uuid_prng.h", line 60.5: 1506-045 (S) Undeclared identifier PRNG_RC_INT. "uuid_prng.h", line 61.1: 1506-277 (S) Syntax error: possible missing ';' or ','? "uuid_prng.h", line 61.3: 1506-273 (E) Missing type in declaration of prng_rc_t. "uuid_prng.h", line 63.8: 1506-166 (S) Definition of function prng_rc_t requires parentheses. "uuid_ui64.h", line 73.3: 1506-166 (S) Definition of function uuid_ requires parentheses. "uuid_ui64.h", line 73.3: 1506-276 (S) Syntax error: possible missing '{'? "uuid.c", line 73.5: 1506-045 (S) Undeclared identifier uuid_uint32_t. "uuid.c", line 74.5: 1506-045 (S) Undeclared identifier uuid_uint16_t. "uuid.c", line 76.5: 1506-045 (S) Undeclared identifier uuid_uint8_t. "uuid.c", line 79.3: 1506-273 (E) Missing type in declaration of uuid_obj_t. "uuid.c", line 83.5: 1506-046 (S) Syntax error. "uuid.c", line 106.9: 1506-277 (S) Syntax error: possible missing ')' or ','? "uuid.c", line 106.9: 1506-045 (S) Undeclared identifier uuid_. "uuid.c", line 108.9: 1506-277 (S) Syntax error: possible missing ')' or ','? make: 1254-004 The error code from the last command is 1.

  geertz# make install
  make: `install' is up to date.

The problem is Mac OS X's case-insensitive file system. It thinks that the INSTALL file fulfills the "install" target. Ick. The workaround is to either a: Rename INSTALL to INSTALL.txt; or b: Put the contents of INSTALL into README and just remove INSTALL from the distribution.

Thanks!

  install: .ALWAYS
         <normal stuff>

  .ALWAYS:

geertz# make gcc -I. -I. -DHAVE_CONFIG_H -O2 -pipe -c uuid.c -fno-common -DPIC -o .libs/uuid.o In file included from uuid.c:44: uuid.h:82: error: conflicting types for 'uuid_t' /usr/include/unistd.h:121: error: previous declaration of 'uuid_t' was here make: *** [uuid.lo] Error 1

The closest post I found to a solution was here:

  http://forums.macosxhints.com/archive/index.php/t-38443.html

But that's ugly. I think that Data::UUID had a similar issue; the solution there was to rename the function:

  https://rt.cpan.org/NoAuth/Bug.html?id=12389

And...yes, that does indeed seem to do the trick. Here's what I did to make it compile:

   rgrep -l uuid_t | grep -v ChangeLog | xargs perl -i -pe 's/uuid_t/ossp_uuid_t/g' 

I imagine that other systems will have UUID functions (Red Hat comes to mind), so it might be worth it to make this change in order to prevent more conflicts in the future.

Apple's unistd.h has the following:

  #ifndef _POSIX_C_SOURCE
  #ifndef _UUID_T
  #define _UUID_T
  typedef __darwin_uuid_t         uuid_t;
  #endif /* _UUID_T */
  #endif /* _POSIX_C_SOURCE */

-- mefisk@gmail.com

Unfortunately, I think that the only solution is to give uuid_t another name. Maybe it can just be done where uuid_t is already defined elsewhere, and then dependent libraries would have to make the same test?

—Theory

Since there are 5 different test cases available for mm, Instead of single message, if we can display either success or fail message after each test completion it would be very easy to parse the test results automatically.

I have made changes in mm_test.c file to implement the above change. I am sending the changed file as a seperate email . Please consider incorporating this change to mm_test.c .

Thanks & Regards,
Mugunth
spikesource.com

If the waiter count is decremented immediatly after the call to pth_wait, this race condition can not happen.

  --- pthsem-2.0.4/pth_sync.c.old 2005-09-22 16:54:36.910273040 +0200
  +++ pthsem-2.0.4/pth_sync.c     2005-09-22 16:56:10.173094936 +0200
  @@ -240,12 +240,13 @@
       pth_mutex_t *mutex = (pth_mutex_t *)(((void **)_cleanvec)[0]);
       pth_cond_t  *cond  = (pth_cond_t  *)(((void **)_cleanvec)[1]);

  +    /* fix number of waiters */
  +    cond->cn_waiters--;
  +
       /* re-acquire mutex when pth_cond_await() is cancelled
          in order to restore the condition variable semantics */
       pth_mutex_acquire(mutex, FALSE, NULL);

  -    /* fix number of waiters */
  -    cond->cn_waiters--;
       return;
   }

  @@ -284,6 +285,10 @@
       cleanvec[1] = cond;
       pth_cleanup_push(pth_cond_cleanup_handler, cleanvec);
       pth_wait(ev);
  +
  +    /* remove us from the number of waiters */
  +    cond->cn_waiters--;
  +
       pth_cleanup_pop(FALSE);
       if (ev_extra != NULL)
           pth_event_isolate(ev);
  @@ -291,9 +296,6 @@
       /* reacquire mutex */
       pth_mutex_acquire(mutex, FALSE, NULL);

  -    /* remove us from the number of waiters */
  -    cond->cn_waiters--;
  -
       /* release mutex (caller had to acquire it first) */
       return TRUE;
   }

mfg Martin Koegler mkoegler@auto.tuwien.ac.at

  I write a programm on Lniux OS machine, it work safely .But now ,I got 
a HP machine ,the prog. not work yet. So I used the test_httpd and 
test_mp ,sadly, all of them not give any answer after the startup .Include the CTRL-C .:(

  The cc version is   HP C/HP-UX Version 11.11.04  

   OS is HP-UX unknown B.11.00 U 9000/800 10714536 unlimited-user license.

  I am not sure ,it enought?

The interface provides functions to set/get the value of a semaphore, increment it with arbitrary values, wait, until the value becomes bigger than a given value (without or with decrementing, if the condition becomes true.

Some documentation and the patch is published at ¤http://www.auto.tuwien.ac.at/~mkoegler/index.php/pth

I am using the patch for a while without any problems. Maybe the names of Flags should be changed and it would be possible to reuse bits.

By the way, the content of the HACKING file seems to be a little bit outdated, eg. the anonymouse CVS server works not any more.

mfg Martin Koegler e9925248@stud4.tuwien.ac.at

I've found an little bug in the Makefile. The Linker-Flags don't effect the libtool, because they are not used. here is a little patch:

--- Makefile.in 2002-12-19 10:19:38.000000000 +0100
+++ ../../PESlibmm/Makefile.in.linkerpatch      2005-02-15 13:20:26.615497000 +0100
@@ -74,14 +74,14 @@
 all: $(LIBS) $(MANS) $(TSTS)

 libmm.la: $(OBJS)
-       $(LIBTOOL) --quiet --mode=link $(CC) -o $@ $(OBJS) \
+       $(LIBTOOL) --quiet --mode=link $(CC) $(LDFLAGS) -o $@ $(OBJS) \
            -rpath $(libdir) -version-info `$(SHTOOL) version -l c -d libtool mm_vers.c`

 mm_alloc.c mm_core.c mm_global.c: mm.h mm_vers.c
 mm.h: config.h

 mm_test: mm_test.lo libmm.la
-       $(LIBTOOL) --quiet --mode=link $(CC) -o $@ mm_test.lo libmm.la
+       $(LIBTOOL) --quiet --mode=link $(CC) $(LDFLAGS) -o $@ mm_test.lo libmm.la

 mm.3: mm.pod
        V1=`$(SHTOOL) version -l c -d short mm_vers.c`; \

Greetings Ralf

What can I do?

fails when run from anywhere besides /usr/local/bin

See also ¤http://www.openldap.org/its/index.cgi/Build?id=3415

1. If built, for example, --with-al, the resulting library should be linked with -lal.
2. *.so files should be installed with permissions 0755, not 644, as Makefile.in forces.
3. Messing with CFLAGS is annoying. If I pass CFLAGS="-O0 -g -Wall" to the ./configure script, I don't want the -g to be stripped.

Patch for 1. and 2.: ¤http://cvs.pld-linux.org/SOURCES/sio-libs.patch

The following bellow is copied from the same error report I sent to Debian maintainers of the pth package, but it seems they are not active now. ¤http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=249328

The error message is:

  configure.in:25: error: undefine: undefined macro:
"+------------------------------------------------------------------------+"
  aclocal.m4:8836: _AC_PTH_ERROR is expanded from...
  aclocal.m4:9184: AC_CHECK_PTH is expanded from...
  configure.in:25: the top level

This error is produced by the macro definitions copied by aclocal (command in automake package) from the file /usr/share/aclocal/pth.m4 (which is included in libpth-dev) to the file aclocal.m4

The error is generated from the "undefine" in line 52 of the file pth.m4 (the name of the macro "_ac_pth_line" is sustituted by its content inside the undefine command, hence the error). I found that commenting that line (with "dnl ##") solves the problem but i'm no expert in m4 (probably the way of definition is wrong).

I found also similar problems reported in first part of the message: ¤http://www.mail-archive.com/pth-users@gnu.org/msg00304.html (there the solution proposed is to remove the macro and substitute the string directly in the two places used).

This makes fsck fail although the filesystem is ok ...

• apache 1.3.29
• mod_ssl 2.8.16-1.3.29
• openssl 0.9.7d
• mm 1.3.0
• Solaris 8

I've configured: SSLSessionCache shmcb:/opt/slt/ses/apache/run/ssl_scache(512000)

The problem only occures if we use client certs. If we do multiple requests on the same ssl session then I get an error the first time the request is handled by the same apache child that has stored the SSL session ID in the cache. All other childs can acces the cache without problems.

trace output in ssl_engine_log (debug level does not provide better info):

[21/Apr/2004 09:48:18 01201] [trace] OpenSSL: Handshake: start
[21/Apr/2004 09:48:18 01201] [trace] OpenSSL: Loop: before/accept initialization
[21/Apr/2004 09:48:18 01201] [trace] OpenSSL: Loop: SSLv3 read client hello A
[21/Apr/2004 09:48:18 01201] [trace] OpenSSL: Loop: SSLv3 write server hello A
[21/Apr/2004 09:48:18 01201] [trace] OpenSSL: Loop: SSLv3 write change cipher spec A
[21/Apr/2004 09:48:18 01201] [trace] OpenSSL: Loop: SSLv3 write finished A
[21/Apr/2004 09:48:18 01201] [trace] OpenSSL: Loop: SSLv3 flush data
[21/Apr/2004 09:48:18 01201] [trace] OpenSSL: Loop: SSLv3 read finished A
[21/Apr/2004 09:48:18 01201] [trace] OpenSSL: Handshake: done
[21/Apr/2004 09:48:18 01201] [info] Connection: Client IP: 192.168.167.99, Protocol: TLSv1, Cipher: RC4-MD5 (128/128 bits)
[21/Apr/2004 09:48:18 01201] [info] Initial (No.1) HTTPS request received for child 0 (server airlock_baumi.ergon.ch:4442)
[21/Apr/2004 09:48:18 01201] [trace] Changed client verification type will force quick renegotiation
[21/Apr/2004 09:48:18 01201] [info] Requesting connection re-negotiation
[21/Apr/2004 09:48:18 01201] [trace] Performing quick renegotiation: just re-verifying the peer
[21/Apr/2004 09:48:18 01201] [error] Cannot find peer certificate chain
[21/Apr/2004 09:48:18 01201] [trace] OpenSSL: Write: SSL negotiation finished successfully
[21/Apr/2004 09:48:18 01201] [info] Connection to child 0 closed with standard shutdown (server airlock_baumi.ergon.ch:4442, client 192.168.167.99)

I wonder about the "Cannot find peer certificate chain" and then the "SSL negotiation finished successfully". hmmm.

If we use dbm instead of shmcb then this problem does not occure.

Thanks for your help
Erwin Huber

When attempting to include uuid.h I get errors because uuid_st and uuid_t are not fully defined. The compiler is unable to determine the size of the objects at compile time and therefor they are not able to be used. I have created a patch file to split out the definition from in uuid.c to be in uuid.h.in and modified the Makefile.in to install the needed header files for using uuid.

  /* include optional Autoconf header */
  #ifdef HAVE_CONFIG_H
  #include "config.h"
  #endif

  /* fallback for POSIX socklen_t */
  #if defined(HAVE_CONFIG_H) && !defined(HAVE_SOCKLEN_T)
  typedef int socklen_t;
  #endif

I traced the problem with gdb and managed to pin-point it to line 1233 in cfg_syn_scan.c (same as line 255 of cfg_syn_scan.l). This line is:

yylval->cpString = strdup(caStr);

I inserted some print statments to test and discovered that the cause is that yylval in this case is a NULL pointer or an invalid address.Whenever I delete a single character from my config file (in any config line of the section) the segfault goes away. That's how I deduced the limit to be 1035 chars in the section before the segfault (ie. 1036 causes a segfault). Strangely enough, if I add a couple of more chars.. my debug line doesn't even show!

Any prompt help regarding a workaround or a fix would be most appreciated.

Regards, Torsten

"hangs" forever check cpu stats: % prstat -s cpu -n 10 1 1 PID USERNAME SIZE RSS STATE PRI NICE TIME CPU PROCESS/NLWP 7771 nelsonhe 936K 464K run 10 0 0:04.35 58% tr/1

OS is Solaris 8

after ./configure and make make-check prints

# make check

Test Suite: OSSP ex (Exception Handling) __________________________________________________________________

Test: basic nested control flow ............................... OK Test: exception value passing ................................. OK Test: variable value preservation ............................. OK Test: exception deferring ..................................... OK Test: exception shielding ..................................... OK Test: cleanup handling ........................................ OK __________________________________________________________________

Test Summary: 6 tests (6 ok, 0 failed), 6 checks (6 ok, 0 failed) Test Suite: OK

make: *** [check] Segmentation fault (core dumped)

int main(void){

    openlog("test", LOG_PID,LOG_LOCAL7);
    syslog(LOG_INFO, "000000000000000000000000000000000000000000000000000000000000");

    syslog(LOG_INFO, "11111111111111111111111111111111111111111111111111111\n");
}

which produces the output: (timestamp added by prefix channel)

[2003-10-31, 11:40:22] 000000000000000000000000000000000000000000000000000000000000
[2003-10-31, 11:40:22] 11111111111111111111111111111111111111111111111111111
00000

Note: only the prefix channel and the file channel were specified int the config file for this test. The error does not appear when only the file channel is present.

  / Excuse me for my English /

  I have self-compiled enviroment with PHP 4.3.3 with MM as static module for Apache 1.3.28. 
When I test this config locally system worked well. But there are some problem appeared in 
real web enviroment. PHP scripts with session support sometimes caused Segmentation Fault 11. 
There are about 12-24 hours pass from apache restart to segfault appeared at about 1 request
per minute scripts that uses sessions. Setting Apache 'MaxRequestsPerChild' options does 
not help (is this good idea?). 

  There are configure scripts:

  PHP:
./configure --with-config-file-path=/etc/httpd --with-mysql=/usr/local --with-apache=../apache_1.3.28 --with-zlib --disable-cli --disable-cgi --disable-ipv6 --with-openssl --with-mysql=/usr/local --with-mysql-sock=/var/lock/mysql.sock --with-mm=/usr/local --enable-sockets --disable-xml --with-mnogosearch=/usr/local 

  Apache:
SSL_BASE=/usr/src/openssl-0.9.7b EAPI_MM=/usr/local ./configure --with-layout=star --activate-module=src/modules/php4/libphp4.a --disable-module=actions --disable-module=cgi --disable-module=include --disable-module=userdir --enable-module=rewrite --enable-module=usertrack --enable-module=ssl --server-uid=www --server-gid=www --disable-rule=SSL_COMPAT

  There are debugger output (gdb /usr/local/sbin/httpd -c /usr/local/core):
GNU gdb 5.3
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-slackware-linux"...
Core was generated by `/usr/local/sbin/httpd -DSSL'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /lib/libcrypt.so.1...done.
Loaded symbols for /lib/libcrypt.so.1
Reading symbols from /usr/local/lib/libmm.so.13...done.
Loaded symbols for /usr/local/lib/libmm.so.13
Reading symbols from /usr/local/lib/mysql/libmysqlclient.so.12...done.
Loaded symbols for /usr/local/lib/mysql/libmysqlclient.so.12
Reading symbols from /usr/lib/libz.so.1...done.
Loaded symbols for /usr/lib/libz.so.1
Reading symbols from /lib/libresolv.so.2...done.
Loaded symbols for /lib/libresolv.so.2
Reading symbols from /lib/libm.so.6...done.
Loaded symbols for /lib/libm.so.6
Reading symbols from /lib/libdl.so.2...done.
Loaded symbols for /lib/libdl.so.2
Reading symbols from /lib/libnsl.so.1...done.
Loaded symbols for /lib/libnsl.so.1
Reading symbols from /lib/libdb.so.2...done.
Loaded symbols for /lib/libdb.so.2
Reading symbols from /usr/lib/libexpat.so.0...done.
Loaded symbols for /usr/lib/libexpat.so.0
Reading symbols from /lib/libc.so.6...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/ld-linux.so.2...done.
Loaded symbols for /lib/ld-linux.so.2
Reading symbols from /lib/libnss_compat.so.2...done.
Loaded symbols for /lib/libnss_compat.so.2
Reading symbols from /lib/libnss_files.so.2...done.
Loaded symbols for /lib/libnss_files.so.2
#0  0x080ec415 in ps_sd_destroy (data=0x8536028, sd=0x423b4e7c) at /usr/src/php-4.3.3/ext/session/mod_mm.c:170
170                     for (prev = data->hash[slot]; prev->next != sd; prev = prev->next);

And there are server configuration: Slackware 9.0 (glibc 2.3.1) with recompiled kernel 2.4.22 on Dual PIII 1000/1GB RAM

The maximum segment size of mm is calculated at compile time and depends on the max seg size of the system, one compiled the library.

It would be more appropriate for the library to calculate the max seg size during initialization of the mm_core by geting this variable from the /proc subsystem. if this fails then it could just use a "hardcoded" value calculated at configuration stage of the library (or even use bits of the code used in the configure script to calculate the maximum available size on the fly...).

gcc -DHAVE_CONFIG_H -O2 -pipe -c cfg_data.c -fPIC -DPIC -o .libs/cfg_data.lo cfg_data.c: In function `cfg_data_set': cfg_data.c:189: parse error before `*' cfg_data.c:189: parse error before `)' make: *** [cfg_data.lo] Error 1

[I do not have OSSP ex installed on this host, should I ? the autoconf has given no error/warning]

thanks

The error is in the comiplation of Apache and seems to be because of missing header files:

./gen_test_char: error while loading shared libraries: libmm.so.13: cannot open shared object file: No such file or directory make[3]: *** [test_char.h] Error 127

Running "make" a second time creates the missing header with 0 bytes content and things get a bit further, but then it crashes again a bit later.

After investigating it shows that timeout setting through setsockopt(SO_RCVTIMEO / SO_SNDTIMEO) does not work as expected. I manually #undef-ined those 2 constants (after system includes) and it worked.

I suggest either system-specific disabling those 2 constants, or implementing a run-time fallback to select (which is normalized and ubiquitous, for sockets) when setting timeouts through setsockopt fails.

• FreeBSD 4.7-STABLE i386
• gcc version 2.95.4 20020320 [FreeBSD]
  
• GNU Make 3.80

I have compiled apache the latest apache 1.3 with php 4.2.3 and lib mm. After several hours, I get a seg fault of apache processes which originate from mod_mm.c at line 186.

It seems that php tries to retrieve a correct session id from libmm, but for some reason, it crashes in the for loop in mod_mm.c. Here is a gdb trace.

Program received signal SIGSEGV, Segmentation fault. 0x40356f4c in ps_sd_lookup (data=0x8082690, key=0x816da24 "0922ecff590e004d7a75919ac38dde0a", rw=0) at mod_mm.c:186

186 for (prev = NULL, ret = data->hash[slot]; ret; prev = ret, ret = ret->next)

(gdb) bt #0 0x40356f4c in ps_sd_lookup (data=0x8082690, key=0x816da24 "0922ecff590e004d7a75919ac38dde0a", rw=0) at mod_mm.c:186

#1 0x403572c8 in ps_read_mm (mod_data=0x403f8e50, key=0x816da24 "0922ecff590e004d7a75919ac38dde0a", val=0xbfffcc94, vallen=0xbfffcc98) at mod_mm.c:326

#2 0x40353f5b in php_session_initialize () at session.c:557

Best, Bastien Duclaux

I'm trying to compile mm1.2.1 on Sparc/Solaris 8. I installed gnu binutils 2.13, then bootstrapped gcc 3.2 using the --with-gnu-ld & --with-gnu-as args.

Now on to mm: ./config appears to work fine. I then do 'make' which also appears to work . I run make test and immediately get a core dump.

I have successfully built mm before with a binary installed version of gcc, but using the sun (/usr/css/bin/) vesions of ld & as.

Any thoughts on what may be wrong? My little ultra 1 compiled all night on gcc, but now I'm afraid it's all for naught if gcc is corrupt.

Thanks for any help.

Regards, D J Brooks