[h323plus] Strange library names due to change in PTLIB macros, proposed patch.

Francisco Olarte (M) folarte at peoplecall.com
Thu Aug 12 12:14:50 EDT 2010


I previously sent the message at the bottom to the list, proposing a
change to sync the release/debug library names
with those used in ptlib ( changing x_r/x_d to x/x_d, which presently
are x_, x__d).

I've decided to further investigate it and made a path. This let's me
do a make both & make both install without problems.
I've then used the patched release to compile gnugk 2.3.2-3 without problem.
I've also compiled yate3, but this is anecdotic since it is patched.

I'd propose the patch for inclusion, as I think these kind of details
maters, and present names look ugly for me.

My path is just two lines, very small, it is this:

folarte at gkaps ~/src/h323plus-cvs $ diff -u openh323u.mak.in*
--- openh323u.mak.in	2010-08-12 16:58:53.077428934 +0200
+++ openh323u.mak.in.~1.8.~	2009-07-25 12:35:51.000000000 +0200
@@ -249,14 +249,14 @@

 ifeq ($(NOTRACE), 1)
 STDCCFLAGS += -DPASN_NOPRINTON -DPASN_LEANANDMEAN
-OH323_SUFFIX = _n
+OH323_SUFFIX = n
 else
 STDCCFLAGS += -DPTRACING
 RCFLAGS	   += -DPTRACING
 OH323_SUFFIX = $(OBJ_SUFFIX)
 endif # NOTRACE

-OH323_BASE  = h323_$(PLATFORM_TYPE)$(OH323_SUFFIX)$(LIB_TYPE)
+OH323_BASE  = h323_$(PLATFORM_TYPE)_$(OH323_SUFFIX)$(LIB_TYPE)
 OH323_FILE  = lib$(OH323_BASE).$(LIB_SUFFIX)

 LDFLAGS	    += -L$(OH323_LIBDIR)


This makes nicer names, both for the compile-tree lib names:

folarte at gkaps ~/src/h323plus-cvs $ ls -l lib
total 183292
lrwxrwxrwx 1 folarte folarte       30 Aug 12 17:02
libh323_linux_x86_64.so -> libh323_linux_x86_64.so.1.22.0
-rwxr-xr-x 1 folarte folarte 10919080 Aug 12 17:02
libh323_linux_x86_64.so.1.22.0
lrwxrwxrwx 1 folarte folarte       32 Aug 12 17:06
libh323_linux_x86_64_d.so -> libh323_linux_x86_64_d.so.1.22.0
-rwxr-xr-x 1 folarte folarte 42136063 Aug 12 17:06
libh323_linux_x86_64_d.so.1.22.0
-rw-r--r-- 1 folarte folarte 85152810 Aug 12 17:02 libh323_linux_x86_64_d_s.a
lrwxrwxrwx 1 folarte folarte       32 Aug 12 18:05
libh323_linux_x86_64_n.so -> libh323_linux_x86_64_n.so.1.22.0
-rwxr-xr-x 1 folarte folarte  8834968 Aug 12 18:05
libh323_linux_x86_64_n.so.1.22.0
-rw-r--r-- 1 folarte folarte 18061356 Aug 12 18:05 libh323_linux_x86_64_n_s.a
-rw-r--r-- 1 folarte folarte 22564616 Aug 12 17:02 libh323_linux_x86_64_s.a
drwxr-xr-x 2 folarte folarte     4096 Aug 12 17:02 obj
drwxr-xr-x 2 folarte folarte     4096 Aug 12 17:02 obj_d
drwxr-xr-x 2 folarte folarte     4096 Aug 12 18:05 objn

and for the installed names

folarte at gkaps ~/src/h323plus-cvs $ ls -l ~/lib/*h323*
lrwxrwxrwx 1 folarte folarte       30 Aug 12 17:07
/home/folarte/lib/libh323_linux_x86_64.so ->
libh323_linux_x86_64.so.1.22.0
lrwxrwxrwx 1 folarte folarte       30 Aug 12 17:07
/home/folarte/lib/libh323_linux_x86_64.so.1 ->
libh323_linux_x86_64.so.1.22.0
lrwxrwxrwx 1 folarte folarte       30 Aug 12 17:07
/home/folarte/lib/libh323_linux_x86_64.so.1.22 ->
libh323_linux_x86_64.so.1.22.0
-r--r--r-- 1 folarte folarte 10919080 Aug 12 17:07
/home/folarte/lib/libh323_linux_x86_64.so.1.22.0
lrwxrwxrwx 1 folarte folarte       32 Aug 12 18:09
/home/folarte/lib/libh323_linux_x86_64_n.so ->
libh323_linux_x86_64_n.so.1.22.0
lrwxrwxrwx 1 folarte folarte       32 Aug 12 18:09
/home/folarte/lib/libh323_linux_x86_64_n.so.1 ->
libh323_linux_x86_64_n.so.1.22.0
lrwxrwxrwx 1 folarte folarte       32 Aug 12 18:09
/home/folarte/lib/libh323_linux_x86_64_n.so.1.22 ->
libh323_linux_x86_64_n.so.1.22.0
-r--r--r-- 1 folarte folarte  8834968 Aug 12 18:09
/home/folarte/lib/libh323_linux_x86_64_n.so.1.22.0
lrwxrwxrwx 1 folarte folarte       25 Aug 12 18:09
/home/folarte/lib/libopenh323.so -> libh323_linux_x86_64_n.so

I made make both, make install, make NOTRACE=1 opt, make NOTRACE=1
install, so the installed link points to the last
one, but verified in between and it pointed to the traced one.




I've found more changes in cvs diff, which are due to having run
configure in between, and getting collisions
with the generated files included in the repository, the same which
happened when I submitted a patch for aclocal
auto running in configure.in

cvs diff output:

*** This is my change.
Index: openh323u.mak.in
===================================================================
RCS file: /cvsroot/h323plus/h323plus/openh323u.mak.in,v
retrieving revision 1.8
diff -r1.8 openh323u.mak.in
252c252
< OH323_SUFFIX = n
---
> OH323_SUFFIX = _n
259c259
< OH323_BASE  = h323_$(PLATFORM_TYPE)_$(OH323_SUFFIX)$(LIB_TYPE)
---
> OH323_BASE  = h323_$(PLATFORM_TYPE)$(OH323_SUFFIX)$(LIB_TYPE)

*** I think this is due to having both the .h and the .h.in  files in
the source tree.

Index: include/openh323buildopts.h
===================================================================

RCS file: /cvsroot/h323plus/h323plus/include/openh323buildopts.h,v
retrieving revision 1.5
diff -r1.5 openh323buildopts.h
0a1
> /* include/openh323buildopts.h.  Generated from openh323buildopts.h.in by configure.  */
26,28c27,38

*** And this three
Index: plugins/video/H.263-ffmpeg/Makefile
Index: plugins/video/H.264/Makefile
Index: plugins/video/H.264/gpl/Makefile

are due to having Makefile.in and Makefile in the source tree, same problem.

Regards.
    Francisco Olarte
Francisco Olarte.

Previous message for reference purposes.



On Tue, Aug 10, 2010 at 5:39 PM, Francisco Olarte (M)
<folarte at peoplecall.com> wrote:
> 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%2Ftrunk%2Fmake%2F&rev=20887&sc=1
>
> http://www.opalvoip.org/websvn/comp.php?repname=Opal&path=%2F&compare[]=%2Fptlib%2Ftrunk%2Fmake at 20850&compare[]=%2Fptlib%2Ftrunk%2Fmake at 20887
>
> 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.
>



More information about the h323plus mailing list