Due to some configure scripts hacking I've been trying to do I've noticed that both H323 plus and old openh323 generate library names (OH323_BASE, OH323_FILE) using from OBJ_SUFFIX via OH323_SUFFIX:

...

...

H323plus, cvs 20100525, openh323u.mak.in

248-endif # OH323_LIBDIR 249- 250-ifeq ($(NOTRACE), 1) 251-STDCCFLAGS += -DPASN_NOPRINTON -DPASN_LEANANDMEAN 252:OH323_SUFFIX = n 253-else 254-STDCCFLAGS += -DPTRACING 255-RCFLAGS += -DPTRACING 256:OH323_SUFFIX = $(OBJ_SUFFIX) 257-endif # NOTRACE 258- 259:OH323_BASE = h323_$(PLATFORM_TYPE)_$(OH323_SUFFIX)$(LIB_TYPE) 260-OH323_FILE = lib$(OH323_BASE).$(LIB_SUFFIX) 261- 262-LDFLAGS += -L$(OH323_LIBDIR) 263-LDLIBS := -l$(OH323_BASE) $(LDLIBS) <<<

...

...

/openh323_v1_19_0_1/openh323u.mak.in

212-endif # OH323_LIBDIR 213- 214-ifeq ($(NOTRACE), 1) 215-STDCCFLAGS += -DPASN_NOPRINTON -DPASN_LEANANDMEAN 216:OH323_SUFFIX = n 217-else 218-STDCCFLAGS += -DPTRACING 219-RCFLAGS += -DPTRACING 220:OH323_SUFFIX = $(OBJ_SUFFIX) 221-endif # NOTRACE 222- 223:OH323_BASE = h323_$(PLATFORM_TYPE)_$(OH323_SUFFIX)$(LIB_TYPE) 224-OH323_FILE = lib$(OH323_BASE).$(LIB_SUFFIX) 225- 226-LDFLAGS += -L$(OH323_LIBDIR) 227-LDLIBS := -l$(OH323_BASE) $(LDLIBS) <<<

But the problem is while old pwlibs always had OBJ_SUFFIX as 'd' 'r' ( for debug/release ):

...

...

pwlib_v1_11_0/make/unix.mak

882- 883:ifndef OBJ_SUFFIX 884-ifdef DEBUG 885:OBJ_SUFFIX := d 886-else 887:OBJ_SUFFIX := r 888-endif # DEBUG 889:endif # OBJ_SUFFIX 890- 891-ifndef OBJDIR_SUFFIX 892:OBJDIR_SUFFIX = $(OBJ_SUFFIX) 893-endif <<<

ptlib changed that in revision 20877

http://www.opalvoip.org/websvn/listing.php?repname=Opal&path=%2Fptlib%2F...

http://www.opalvoip.org/websvn/comp.php?repname=Opal&path=%2F&compar...

from 'd'/'r' to '_d'/''

and ajusted it's paths acordingly, but h233plus did not, so the current paths end up being

lrwxrwxrwx 1 gnugk gnugk 31 Aug 10 16:46 libh323_linux_x86_64_.so -> libh323_linux_x86_64_.so.1.22.0 lrwxrwxrwx 1 gnugk gnugk 31 Aug 10 16:46 libh323_linux_x86_64_.so.1 -> libh323_linux_x86_64_.so.1.22.0 lrwxrwxrwx 1 gnugk gnugk 31 Aug 10 16:46 libh323_linux_x86_64_.so.1.22 -> libh323_linux_x86_64_.so.1.22.0 -r--r--r-- 1 gnugk gnugk 10059909 Aug 10 16:46 libh323_linux_x86_64_.so.1.22.0 lrwxrwxrwx 1 gnugk gnugk 24 Aug 10 16:46 libopenh323.so -> libh323_linux_x86_64_.so

This is only cosmetic ( it affects some makefiles I have which try to locate the _r names, but that's another story ), but maybe changing the names so the names are

libh323_linux_x86_64.so / libh323_linux_x86_64_d.so

instead of

libh323_linux_x86_64_.so and libh323_linux_x86_64__d.so

(double underscore in second ) is worthwile

This could be done just by changing

259:OH323_BASE = h323_$(PLATFORM_TYPE)_$(OH323_SUFFIX)$(LIB_TYPE)

to

259:OH323_BASE = h323_$(PLATFORM_TYPE)$(OH323_SUFFIX)$(LIB_TYPE)

( underscore zapped between the two macros )

and will possibly need changing

250-ifeq ($(NOTRACE), 1) 251-STDCCFLAGS += -DPASN_NOPRINTON -DPASN_LEANANDMEAN 252:OH323_SUFFIX = n 253-else

to

250-ifeq ($(NOTRACE), 1) 251-STDCCFLAGS += -DPASN_NOPRINTON -DPASN_LEANANDMEAN 252:OH323_SUFFIX = _n 253-else

(underscore added @ 252 )

to keep the notrace suffix pretty.

Regards.

Francisco Olarte.