BaCon Bits

For discussions about programming, programming questions/advice, and projects that don't really have anything to do with Puppy.
Post Reply
Message
Author
big_bass
Posts: 1740
Joined: Mon 13 Aug 2007, 12:21

#91 Post by big_bass »

Creating and linking to libraries created with BaCon

here it is with the examples given in the documentation


I added showing the code output
using these two test files

call this libdemo.bac

Code: Select all

FUNCTION bla (NUMBER n)
LOCAL i
i = 5 * n
RETURN i
END FUNCTION 

call this program.bac

Code: Select all

PROTO bla
x = 5
result = bla(x)
PRINT result 

let's make the lib using the -f option

Code: Select all

bacon -f libdemo.bac 
Converting 'libdemo.bac'... done.
Compiling 'libdemo.bac'... done.
Program 'libdemo.so' ready.


let's link the lib to the program using the -l option
notice that here you don't use the lib prefix in the command line
but this is the correct way to link libdemo.so to the program

Code: Select all

 bacon -l demo program.bac 
Converting 'program.bac'... done.
Compiling 'program.bac'... done.
Program 'program' ready.




let's check if the library is seen by the ldd command

Code: Select all

 ldd /root/bacon-examples/program
linux-gate.so.1 => (0xffffe000)
libm.so.6 => /lib/libm.so.6 (0xb7fbc000)
libdl.so.2 => /lib/libdl.so.2 (0xb7fb8000)
libdemo.so => /usr/lib/libdemo.so (0xb7fac000)
libc.so.6 => /lib/libc.so.6 (0xb7eb1000)
/lib/ld-linux.so.2 (0xb7fdf000)

shows that the documentation is correct the libdemo.so is linked and understood by ldd
as being a real shared library *because it has a lib prefix

let's prove if the program runs

Code: Select all

./program
25


the output is 25



everything works as described (there needs to be some "re-thinking" about how this
really works ) in order to benefit from this advantage of having shared libs

Joe

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#92 Post by sunburnt »

I must be missing something with libraries as to why they`re important.
They are shared code of any type, but isn`t a std. exec. also?

What do libraries do that an exec. can`t? "Must be in the sharing..."
Are they usable in some way that an exec. isn`t?

A copy of an exec. is put in ram each time it`s run, making for many copies.
But libraries there`s only one copy of in ram? ( This would make it useful. )
If this is so, are the libraries only kept in ram while in use by some app.?

User avatar
GatorDog
Posts: 138
Joined: Tue 12 Sep 2006, 16:43

#93 Post by GatorDog »

Hi Joe,
Using libdemo.bac and program.bac,

First I put everything in a single program and just called "bla" as normal function. I'll call this the "complete" program.

Code: Select all

FUNCTION bla (NUMBER n)
LOCAL i
i = 5 * n
RETURN i
END FUNCTION 

x = 5
result = bla(x)
PRINT result
The binary for this file is 34k (33,982)

Next I IMPORTed the libdemo.so into program.bac

Code: Select all

IMPORT "bla" FROM "libdemo.so" TYPE long

x = 5
result = bla(x)
PRINT result
This gave a file size of 34K (34096), just a few bytes larger than the
"complete" program. Note here that no path is specified to libdemo.so,
which is in /usr/lib. (For ref. "ldd" does not show a link to libdemo)

Then I compiled per above example using bacon -l demo program.bac.
The size is 38k (37,997).
(By the way, BaconGUI also has the option of compiling using linking.)

Next I tried this:

Code: Select all

PRINT "do nothing"
Compiled binary for this is 34k.
Then I "linked" it with a hug.so file and compiled. That gave a binary of 38K.
(It would appear that linking increases the binary size by 4k.)
Then I compiled using INCLUDE "/usr/share/BaCon/hug.bac" . This binary is 177k.
Next I compiled using INCLUDE "/usr/share/BaCon/hug_imports.bac". This
binary is 51K.

If I understand it, linking is a soft link. ie. the lib file needs to exist some
where in the path. While using INCLUDE hard codes the path.

Going by binary size alone, linking has a definite advantage.
But, what about memory usage. Does the whole linked file get loaded into
memory when the program is run; or do modules get loaded as called.
Someone know about this?

Because when hug.bac is INCLUDEd in a program, you have the option
of only loading the modules specifically needed, thereby reducing memory
usage.

Regardless, it would seem to be more appropriate to have libhug.so than
hug.so. Then hug_imports.bac could point to libhug. The uptic being that
either soft or hard linking could be accommodated.
EDIT: See next post about why linking doesn't seem to work for hug.

Well, don't know if that classifies as "re-thinking", or even thinkin', but there you have it. :roll:

rod
Last edited by GatorDog on Wed 28 Sep 2011, 00:09, edited 1 time in total.

User avatar
GatorDog
Posts: 138
Joined: Tue 12 Sep 2006, 16:43

#94 Post by GatorDog »

I decided I'd better try out linking libhug in an actual program.
Turns out a program using hug features won't convert if hug (libhug) definitions
aren't available before conversion. The conversion process executes before the program is compiled,
so linking hug is after the fact. Unless there's a way to PROTO wildcard the
whole libhug.so.

So the memory savings of linking still stand, just apparently doesn't apply to hug.

Big_Bass, a few post back, when you compiled pFontselect and linked to
libhug.so (bacon -l hug pfontselect.bac), did you first remove the
INCLUDE "/usr/share/BaCon/hug.bac" line from program? If not, I think that
may be why you succeded with linking hug :?:

rod

big_bass
Posts: 1740
Joined: Mon 13 Aug 2007, 12:21

#95 Post by big_bass »

instead of reviewing some standard linux package differences
between compiling static and compiling shared


the focus here is what does all this mean when we use BaCon
"most" of the binaries we compile in BaCon have no dependencies
they are stand alone apps without statically compiled libs

some apps have a dependency of hug.so as being the only
"special" shared dependency

but we can link to a shared library in the next example using curl
the linux app curl http://curl.haxx.se/download.html (not the bacon curl.bac)

-----------------------------------------------------------
using the official demo from the main bacon website

Code: Select all

 ./curldemo3    

Symbol not found in library /usr/lib/libcurl.so.3: undefined symbol: curl_easy_pause


this means that you dont have curl the "real program" installed
for me I compiled and made this package curl-7.21.4-i486-1.txz
the error reads no shared lib--> libcurl.so.3
for this reason the BaCon program curldemo3 can not read the library and get the needed info



now install the curl-7.21.4-i486-1.txz package and try again

Code: Select all

 ./curldemo3 
Downloaded 'documentation.pdf' using CURL version: libcurl/7.21.4 OpenSSL/0.9.8e zlib/1.2.3



this shows that BaCon compiled apps can and do utilize the shared libraries
in the same way that when you install other linux programs

Joe
Last edited by big_bass on Thu 29 Sep 2011, 14:27, edited 1 time in total.

big_bass
Posts: 1740
Joined: Mon 13 Aug 2007, 12:21

#96 Post by big_bass »

Hey rod @GatorDog
Big_Bass, a few post back, when you compiled pFontselect and linked to
libhug.so (bacon -l hug pfontselect.bac), did you first remove the
INCLUDE "/usr/share/BaCon/hug.bac" line from program? If not, I think that
may be why you succeded with linking hug Question
a new post to keep it clear
I was able to link using the commands
and the ldd did show it was linked but the app wouldnt run
with libhug.so this is why I was confused
I removed the libhug.so example (why the naming hug.so and not libhug.so still remains a mystery)
and replaced the docs with these two confirmed
examples below

the libdemo example works correctly and
this one works correctly using the curldemo3 example
having a shared lib

a lot was gained by confirming these tests
and documenting the steps
if we end up with the smallest possible
binaries that work correctly its a win ,win and no losses

*I used the term re-thinking as
taking a deeper look at this
because there are more things we still can do
using shared libs

Joe

big_bass
Posts: 1740
Joined: Mon 13 Aug 2007, 12:21

#97 Post by big_bass »

yes!! stop the press

libhug.so can be used and can be linked :D

mystery solved 8)

hug_imports.bac hard codes this pre set as hug.so
and it looks for the file hug.so and expects it to be in the same place as
the compiled app regardless if hug.so is the the path or not
the lld path is not used !

with this revealed puzzle piece I was able to change the name to
libhug.so

edit /usr/share/BaCon/hug_imports.bac

' Imports when HUG is used as shared object
CONST HUG_lib$ = "./libhug.so"

and you must modify this line of code in your app that you want to compile
from
INCLUDE "/usr/share/BaCon/hug.bac"

to
INCLUDE "/usr/share/BaCon/hug_imports.bac"

I opened hug.bac and saved it as libhug.bac

Code: Select all

 bacon -f libhug
Converting 'libhug.bac'... done.
Compiling 'libhug.bac'... done.
Program 'libhug.so' ready.

Code: Select all

./pFontSelect-104-sa
Could not open library ./libhug.so: cannot open shared object file: No such file or directory


now place it (libhug.so)in the same directory as the program pFontSelect-104-sa then it works

and the binary is now only 79k ! and it works

********************************
SOLVED
********************************
now the correct way it goes in the path but now hard coded
but not seen by ldd this way other compiled apps look for it there also

edit /usr/share/BaCon/hug_imports.bac

' Imports when HUG is used as shared object
CONST HUG_lib$ = "/usr/lib/libhug.so"


Joe

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#98 Post by sunburnt »

Let me be the first to offer congrats on your coup big_bass.
I knew you, or vovchek, or Barry would figure it out.

To "enable" it, don`t you have to run /etc/ld.so.cache ?

# Suggestion... Post your new shared library so we`re fine feathered too.
Also post with it instructions for setting it up, and usage in Bacon-Hug.
And make a copy post at the Bacon forum for pjot and the folks there.
Last edited by sunburnt on Sat 01 Oct 2011, 20:22, edited 1 time in total.

User avatar
GatorDog
Posts: 138
Joined: Tue 12 Sep 2006, 16:43

#99 Post by GatorDog »

Well, I don't think there was a coup :lol:
Barry confirmed a location of /usr/lib/hug.so
Big_Bass is making it copasetic by working through the significance of the "lib" prefix.

Re-cap:
To create and link-to a library, refer to Big_Bass previous posts and the
official instructions here.
The library filename needs to be prefixed with "lib". ex libdemo.so
and placed in /usr/lib/... (at least for puppy, this is in the library search path).

Now the hug library is a bit of a special case. This is my take on it, YMMV.
As is implemented in the devx and pet, hug.so is located in /usr/lib/ .
That's fine. The mechanism to link hug.so (special case) is through using
hug_imports.bac ie. INCLUDE "/usr/share/BaCon/hug_imports.bac"
As Big_Bass stated, the first line of code in hug_imports.bac is

Code: Select all

CONST HUG_lib$ = "/usr/lib/hug.so"
And as I say, this is the implementation as of today.
I think Joe is suggesting that as a mater of (linux) convention, hug.so should
be named libhug.so
------------------------------------
[sidebar]
I would point out that Peter calls it hug.so; maybe because it isn't linked to
with the conventional linking method.
[/sidebar]
------------------------------------

My take again here (I could easily be corrected on this)-
hug.so is not in the puppy iso. So to use a Bacon GUI (HUG) program, either
the devx has to be loaded or the bacon pet package installed.
(This is to take advantage of smaller program size as a result of using hug_imports.bac.
This does not apply to a Bacon program that has been compiled to standalone. ie. compiled using INCLUDE "/usr/share/BaCon/hug.bac"

So, to create the smallest Bacon GUI programs, hug.so (or libhug.so) needs
to be in the puppy iso. The alternative is to compile them standalone using hug.bac;
the tradeoff being a significantly larger (but portable) program.

Guess that doesn't solve anything, just my 2 cents.
rod

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#100 Post by sunburnt »

I found a 76 KB difference in compiled size, but that may vary as Rod reported.

Barry said: /etc/ld.so.cache only loads libs if they begin with lib and end in .so
He is probably correct with his years of Puppy building experience.

GatorDog; Once there`s a good copy of libhug.so, start a new post for it.
There you can post a few Bacon app examples showing the init code for it.

Once it seems good-to-go, We`ll ask Barry to add it to the ISO, it`s only 284 KB.
I think he`ll like the idea as he made a proxy GUI for Puppy with Bacon-Hug.
Maybe he`ll replace Puppy`s GUIs with executables and depreciate gtkDialog.

I`m trying to judge the size difference between Bacon-Hug and Bash-gtkDialog.
It`s a bit of a mix of course as Bacon uses Bash too, and Bash uses it`s execs.

User avatar
GatorDog
Posts: 138
Joined: Tue 12 Sep 2006, 16:43

#101 Post by GatorDog »

Once there`s a good copy of libhug.so ...
You already have a copy. Just copy or rename hug.so to libhug.so
post a few Bacon app examples showing the init code for it.
You've already been using it. When you use

Code: Select all

INCLUDE /usr/share/BaCon/hug_imports.bac"
hug_imports takes care of linking to hug.so/libhug.so

If hug_imports.bac hasn't been edited, it has a path set to /usr/lib/hug.so. (the default setup AFAIK)
If you prefer to use the name libhug.so, edit the top line in hug_imports.bac to /usr/lib/libhug.so (and make sure the file is there).

However, this does not conform to the model "as of today"; and that would make a bacon gui program
less compatible/portable amongst puppians. Which of course is counter productive. I know I would get
frustrated if I had to sort out and rename shared library files to get a program to run.

I think there's a kinda' chicken/egg thing goin' on here. :roll:

GatorDog

Saw a good 'make you think' movie on netflix recently, The Encounter

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#102 Post by sunburnt »

I`ll have to look up the Encounter and see what it`s about.

# Perhaps have both hug.so and libhug.so in /usr/lib in Puppy`s ISO?
Previously written apps would still work with hug.so, but new apps could
be written for libhug.so for a future when it`s a normal library.
Seems like a good direction even though Bacon is the only thing to use hug.


# Qs: Buttons highlight on mouse hover, any way to tell which one? REGISTER?
............ Or what to use instead of a button for a slide out sub menu hover spot.

You may have answered this... How to use any type of icons on buttons, etc.?

User avatar
GatorDog
Posts: 138
Joined: Tue 12 Sep 2006, 16:43

#103 Post by GatorDog »

# Qs: Buttons highlight on mouse hover, any way to tell which one? REGISTER?
............ Or what to use instead of a button for a slide out sub menu hover spot.
AMPG
You may have answered this... How to use any type of icons on buttons, etc.?
AMPG

Next question? :twisted:

The button mouse hover is certainly generating an event; but using it is another mater.
Something you can do with your existing code. Your top button opens and closes (expand/contract) it's window.
You can change the button text at your pleasure. So when it's closed, button text is "Open Squash List".
And when it's open, "Close Squash List". Personally I don't like gui's flip-flopping around just because the
mouse pointer happens to pass over something. And tooltips should be used sparingly. Too often they
obfuscate more than they illuminate.

In vovchik's pLogo, he imports his own icon and uses it in the title bar. There may be a similar
technique for buttons. Seek and ye shall find.

Rod

big_bass
Posts: 1740
Joined: Mon 13 Aug 2007, 12:21

#104 Post by big_bass »

Hey Rod @GatorDog

your recent summary of events was very clear

I think it will be useful to document
the steps better and confirm the results on different computers
I have a different glibc so I dont know if my recompiled binary
will work on newer puppy versions or not

but by having to recompile everything the steps are confirmed
I included all the edited files for clarity as only a reference
I would like that people use your original example pFontSelect-104-sa
with this new shared lib info
*pFontSelect-104-sa is now 79kb a saving of 108kb smaller this way
so worth all the research and testing that was involved

All edits below applied to these sources already
the binary was recompiled on txz_pup (same glibc as puppy 4.12)
notes documented by Joe Arose 9-29-2011

this is a note that was placed with the sources

===================
1.) EDIT SOURCE CODE
===================
pFontSelect-104-sa is 187kb "as is" in example one of the first post on the first page

http://www.murga-linux.com/puppy/viewtopic.php?t=69647

edit pFontSelect-104-sa.bac original source code

from (notice I just commented this statement out to be clearer)
'INCLUDE "/usr/share/BaCon/hug.bac", ATTACH, BUTTON, CALLBACK, CANVAS, CIRCLE, DISPLAY, ENTRY, FONT, FRAME, GET, GRAB$, HSEPARATOR, HUGOPTIONS, INIT, LIST, MARK, PROPERTY, QUIT, RADIO, SET, SPIN, SQUARE, STOCK, SYNC, TEXT, TIMEOUT, WINDOW

to
INCLUDE "/usr/share/BaCon/hug_imports.bac"

*notice here that the ,ATTACH ,BUTTON ... and so forth are NOT added to the end of hug_imports.bac

=================================================================================


===================
2.) EDIT hug_imports.bac
===================

from
' Imports when HUG is used as shared object
CONST HUG_lib$ = "./hug.so"

to
' Imports when HUG is used as shared object
CONST HUG_lib$ = "/usr/lib/libhug.so"

=================================================================================



===================
3.) make the shared lib libhug.so
===================
open hug.bac and save it as libhug.bac

bacon -f libhug

Converting 'libhug.bac'... done.
Compiling 'libhug.bac'... done.
Program 'libhug.so' ready.

compile pFontSelect-104-sa.bac ( I used my hacked geany)
or simply bacon pFontSelect-104-sa.bac
pFontSelect-104-sa is now 79kb a saving of 108kb smaller this way


===================
4.) place libhug.so in /usr/lib
===================


a special note that libhug.so is not a compile time dependency
it is however a run time dependency
which means it is not needed in the iso at compile time

this is good if you want to keep up to date with hug.bac
and keep it updated


Peter the BaCon developer decides
what names to use (since he writes the source code and docs)
I prefer libhug.so
for the following of the Bacon Documentation is better understood
and for those that are used to thinking about shared libs (on linux)
having the *.so and the prefix lib are very familiar

I am just glad that smaller binaries result
using shared libs whatever the name is

a rose by any other name is still a rose :D

Joe
Attachments
pFontselect-1.0.4-shared.tar.gz
(94.39 KiB) Downloaded 359 times

big_bass
Posts: 1740
Joined: Mon 13 Aug 2007, 12:21

#105 Post by big_bass »

GatorDog
If hug_imports.bac hasn't been edited, it has a path set to /usr/lib/hug.so
thats not correct the official file is here (maybe you have an already edited file )
http://www.basic-converter.org/hug_imports.bac.html

"as is" without editing hug_imports.bac

' Imports when HUG is used as shared object
CONST HUG_lib$ = "./hug.so"



what does the trick though is telling the compiled app
where to look for the the libhug.so or hug.so
this is why we do edit
CONST HUG_lib$ = "/usr/lib/libhug.so"

since this is a run time library
that needs to be hard coded into the program

*I just dont want anyone else to trip up
and spend a lot of time just trying to get started correctly
figuring out what is needed to compile a shared lib

P.S a big thanks for all your examples ,comments and code

I will be going over all the Bacon *.bac files
and reporting things as they come I will
open a new thread for a more basic getting started with the official examples
as the focus ...and continue using and testing all your great apps here

Joe

User avatar
GatorDog
Posts: 138
Joined: Tue 12 Sep 2006, 16:43

#106 Post by GatorDog »

If hug_imports.bac hasn't been edited, it has a path set to /usr/lib/hug.so

thats not correct the official file is here (maybe you have an already edited file )
http://www.basic-converter.org/hug_imports.bac.html
I stand corrected :oops:
-----------------
Just had a power outage :evil:
So I booted a fresh pup 528 into memory (pfix=ram).
- /usr/lib/hug.so is there.
- /usr/share/BaCon/ dir is there with two lang definition files. (For nicoedit and vim I think)

I ran a couple of bacon programs that were compiled with hug_imports.bac pointing to /usr/lib/hug.so
One file ran fine. The other failed. It expected a feature available in a later hug verson. (see below)

This points to a need for version tracking for hug. Bacon has a reserved variable $VERSION, but
this is for bacon itself and does not apply to hug.

The only way I know to find the hug version number is to open hug.bac. Peter maintains a commented
section there that includes the hug version number.

I've been backing up older files by naming them (for example) hug.59.so, hug.60.so, etc.

Simply having /usr/lib/hug.so (or libhug.so) gives no clue to what your working with.
In earlier post in this thread, I made tar files for the latest (beta) versions of hug as they became available.

Another point I'll mention; the hug_imports.bac version is loosely tied to the hug.bac/hug.so version.
To wit-
- hug_imports.bac is the mechanism to load HUG features from the shared library, hug.so
- When Peter adds a new HUG feature, hug_imports.bac is updated to include loading those new features.
- If a program is compiled with the new hug_imports.bac, it expects all the features are available in /usr/lib/hug.so
- If hug.bac is only updated for a bug fix, then hug_imports.bac version doesn't change, as there is no new features added.
. (Probably an oversimplification but works for this discussion)
- This is why the second program I tried didn't run. The program was compiled with a newer hug_imports, which was looking for
. /usr/lib/hug.so, which it found. However, that hug.so is outdated (pup 528), so the program failed because it couldn't
. import a feature from hug.so

So version control is another issue to consider when offering bacon programs for Puppy.
I really don't want to be limited to the "offical" hug version in Puppy. The current beta versions of Bacon, hug and hug_imports
have several bug fixes and some new features.

I don't follow gtkDialog closely, but it seems that it too is under development. Therefore new scripts require the latest gtkDialog version.
So, wonder how that is being addressed?

In conclusion, to shoot for success, this is what I've done with the programs that I've recently posted.
1.) I include the source code. Anyone that has bacon set up can compile it on their machine.
. They can use hug_imports.bac for the smallest possible program. And I comment in the
. source what versions of bacon, hug etc. were used.
2.) I include a "standalone" version of the binary/executable program. This is compiled using INCLUDE ".../hug.bac".
. It makes for a significantly larger program, but, it should only have common linux dependencies, (gtk etc.) and
. should run independent of any bacon related settings or programs.

Your Mi!eage May Vary,
GatorDog

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#107 Post by sunburnt »

Hey guys, an item I looked into that GatorDog spoke of.

I ran "dd" on hug.so to see if I could find it`s version.
I found "1.0 build 24 beta r3" about half way down the output in rxvt.

Code: Select all

dd if=hug.so [of=hug.dd]
Providing the "of=" to make an output file just makes another copy of hug.
It seems to throw rxvt for a loop, I had to shut it down after doing this.

I can`t get sed to do anything with the output as it`s a binary file.
dd can convert, but I don`t know what it`s capabilities are.
If the output could be convert to text then sed might work.
It`s just one big long string with no LF or CR so grep isn`t much good.

seaside
Posts: 934
Joined: Thu 12 Apr 2007, 00:19

#108 Post by seaside »

sunburnt wrote:Hey guys, an item I looked into that GatorDog spoke of.

I ran "dd" on hug.so to see if I could find it`s version.
I found "1.0 build 24 beta r3" about half way down the output in rxvt.

Code: Select all

dd if=hug.so [of=hug.dd]
Providing the "of=" to make an output file just makes another copy of hug.
It seems to throw rxvt for a loop, I had to shut it down after doing this.

I can`t get sed to do anything with the output as it`s a binary file.
dd can convert, but I don`t know what it`s capabilities are.
If the output could be convert to text then sed might work.
It`s just one big long string with no LF or CR so grep isn`t much good.
Hey sunburnt,

How about the command "strings".

Regards,
s

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#109 Post by sunburnt »

SeaSide; That did it !!! I`m always amazed at the number of exec. there are.
Unix has been around sooo long that there`s a file for almost everything.

This gets the "build version" from /usr/lib/hug.so

Code: Select all

strings /usr/lib/hug.so |grep ' build '

User avatar
GatorDog
Posts: 138
Joined: Tue 12 Sep 2006, 16:43

#110 Post by GatorDog »

seaside,
Wow!
strings
Who knew?

Thank you for taking time to share that. That's (another) one I hadn't run into before.

sunburnt,
The "build" that is reported is the version of "Bacon" that was used to generate the hug.so file.
So the search goes on.
-------------------

hug_imports.bac looks for hug.so
Q. If a new version of hug.so includes the version number (hug.62.so), can a pet package not only
put it in /usr/lib/ but also take care of linking hug.so/libhug.so to the new hug.62.so?

GatorDog

Post Reply