Recent changes to bugs

#15 Build for 64-bit architectures

DRS David Soft — Mon, 15 Dec 2025 12:00:46 -0000

Incorporated changes from both patches in the new repo:
https://github.com/steinm/pxlib/pull/9

#13 Bugg in paradox.c

DRS David Soft — Mon, 15 Dec 2025 11:41:40 -0000

This can be closed as it was addressed in: https://github.com/steinm/pxlib/pull/7

#15 Build for 64-bit architectures

Kenneth Porter — Fri, 24 Aug 2018 17:57:26 -0000

This fixes PX_put_data_long on 64-bit systems, where long int is 64 bits.

#15 Build for 64-bit architectures

Kenneth Porter — Tue, 21 Aug 2018 14:45:30 -0000

Attached is unified diff of edits needed to get rid of most of the warnings when built on CentOS 7.5. There's 3 remaining warnings about aliased pointers that need a little work but the code should work.

Build for 64-bit architectures

Kenneth Porter — Tue, 21 Aug 2018 09:39:36 -0000

Various serious warnings are issued when building for 64-bit due to the change in pointer size. Patch under development.

#14 PX_HAVE_GSF not defined consistently

Jean Bréfort — Sun, 24 Apr 2016 13:31:27 -0000

Also, the paradox-gsf.h header file should be installed only if pxlib supports gsf.
Note that the way used to detect gsf is not that good, pkg-config should be used instead.

PX_HAVE_GSF not defined consistently

Michael Tautschnig — Mon, 09 Jun 2014 23:32:45 -0000

Hi,

During a rebuild of all Debian packages in a clean sid chroot (using cowbuilder
and pbuilder) the build failed with the following error. Please note that we
use our research compiler tool-chain (using tools from the cbmc package), which
permits extended reporting on type inconsistencies at link time.

[...]
libtool: link: x86_64-linux-gnu-gcc -shared -fPIC -DPIC .libs/paradox.o .libs/px_head.o .libs/px_misc.o .libs/px_io.o .libs/px_memory.o .libs/px_memprof.o .libs/px_error.o .libs/px_encode.o .libs/px_crypt.o .libs/gregor.o -lgsf-1 -O2 -Wl,-soname -Wl,libpx.so.0 -o .libs/libpx.so.0.6.5

error: conflicting function declarations "get_px_head"
old definition in module paradox file px_head.h line 3
struct px_head * (struct px_doc *, struct px_stream *)
new definition in module px_head file px_head.c line 25
struct px_head * (struct px_doc *pxdoc, struct px_stream *pxs)

reason for conflict at pxs->px_stream->s in types listed below (union/union):
composite type component counts differ (4/2)
union {
struct _IO_FILE * fp;
void * stream;
struct _GsfInput * gsfin;
struct _GsfOutput * gsfout;
}
union {
struct _IO_FILE * fp;
void * stream;
}

So this will work fine, but it does highlight what might be unintentional: it seems px_head.c sees paradox.h without PX_HAVE_GSF being defined. This is due to the fact that PX_HAVE_GSF is defined in paradox-gsf.h rather than config.h. This may make things prone to errors, if not already causing one.

Best,
Michael

Bugg in paradox.c

Dan — Tue, 09 Oct 2012 10:00:39 -0000

I belive that there is a bugg in paradox.c on line 2865 ( ver 0.6.5).
mbblockhead have type TMbBlockHeader2. It shall be TMbBlockHeader3.

/Dan

Compiling pxview with a custom-built pxlib fails

Zoltan P — Sun, 16 Sep 2012 18:25:24 -0000

Hi,

when compiling pxview with a pxlib that has been installed to a nonstandard location, the configure script fails because it is not able to find pxlib. The source of the problem is that in the configure script the math library is not linked to the test executable, hence building fails, but the error message is wrong. A proper fix would be to link the math library (-lm) to the tests of configure.
A workaround is to set the LIBS variable to "-lm" when running the configure script.

Example:

~/Desktop/profoto-dump/pxview-0.2.5$ ./configure --with-pxlib=/home/zoltanp/Desktop/profoto-dump/pxview-0.2.5/../pxlib

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
....
checking for localtime... yes
checking for PX_timestamp2string in -lpx... no
configure: error: libpx not found. You will need at least libpx 0.4.4

contents of config.log:

configure:23041: checking for PX_timestamp2string in -lpx
configure:23071: gcc -o conftest -g -O2 conftest.c -lpx -L/home/zoltanp/Desktop/profoto-dump/pxview-0.2.5/../pxlib/lib >&5
/home/zoltanp/Desktop/profoto-dump/pxview-0.2.5/../pxlib/lib/libpx.so: undefined reference to `fmod'
collect2: ld returned 1 exit status
configure:23077: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME "pxview"
| #define PACKAGE_TARNAME "pxview"
| #define PACKAGE_VERSION "0.2.5"
....
| /* Override any gcc2 internal prototype to avoid an error. */
| #ifdef __cplusplus
| extern "C"
| #endif
| /* We use char because int might match the return type of a gcc2
| builtin and then its argument prototype would still apply. */
| char PX_timestamp2string ();
| int
| main ()
| {
| PX_timestamp2string ();
| ;
| return 0;
| }
configure:23102: result: no
configure:23107: error: libpx not found. You will need at least libpx 0.4.4

As it can be seen, the missing function is "fmod". This function is located in the math library (-lm).

Workaround is:

$ LIBS=-lm ./configure --with-pxlib=/home/zoltanp/Desktop/profoto-dump/pxview-0.2.5/../pxlib

In this case confgure finishes correctly.

pxlib causes stack smashing in pxview when blobs are used

Zoltan P — Sun, 16 Sep 2012 18:13:10 -0000

Hi,

when trying to use pxview with databases that have binary blobs in them, a stack smashing error gets generated. Example output below:

$ ./pxview.elf "/tmp/profoto/Profoto/profoto.db" -b /tmp/profoto/Profoto/profoto.MB -p img --blobextension=bmp -x -o index.htm
*** stack smashing detected ***: ./pxview.elf terminated
======= Backtrace: =========
/lib/i386-linux-gnu/libc.so.6(__fortify_fail+0x45)[0xb7690c75]
/lib/i386-linux-gnu/libc.so.6(+0xe8c27)[0xb7690c27]
/home/zoltanp/Desktop/profoto-dump/pxlib-0.6.5/../pxlib/lib/libpx.so.0(+0x11151)[0xb777f151]
/home/zoltanp/Desktop/profoto-dump/pxlib-0.6.5/../pxlib/lib/libpx.so.0(PX_open_blob_fp+0x3a7)[0xb7775d17]
/home/zoltanp/Desktop/profoto-dump/pxlib-0.6.5/../pxlib/lib/libpx.so.0(PX_open_blob_file+0x4e)[0xb7775dee]
./pxview.elf[0x804a00c]
/lib/i386-linux-gnu/libc.so.6(__libc_start_main+0xf3)[0xb75c1113]
./pxview.elf[0x804fb99]
======= Memory map: ========
08048000-08054000 r-xp 00000000 08:06 961263 /home/zoltanp/Desktop/profoto-dump/pxview.elf
08054000-08055000 r--p 0000b000 08:06 961263 /home/zoltanp/Desktop/profoto-dump/pxview.elf
..... cut the memory map ...
b77c6000-b77c7000 rw-p 0001e000 08:06 5720787 /lib/i386-linux-gnu/ld-2.13.so
bfbeb000-bfc0c000 rw-p 00000000 00:00 0 [stack]
Aborted

This happens on an Ubuntu 11.10 system, both with the pxlib from the distribution, and also with the pxlib compiled from source.

The system is:
$ uname -a
Linux e6pzoltanlaptop 3.0.0-25-generic-pae #41-Ubuntu SMP Mon Aug 13 18:20:25 UTC 2012 i686 i686 i386 GNU/Linux

An incorrect workaround I found is to recompile pxlib with stack smashing protection disabled, but that is not solving the main issue.

Versions 0.6.0, 0.6.4 and 0.6.5 all generate this error.

Unfortunately valgrind is not able to catch the source of this error.

The files that generate this error contain private data, so I'm not uploading them here; Feel free to contact me, and I can send a minimal crashing example.