BaCon Bits

[GatorDog]

OK Joe,

"light" it is. And 2nd request is even easier.
Just enter the text you'd like to see as default and click "Apply".
The next time you run pFontselect, it should be there, along
with your previous setup. ie. Font name, Style, Size

How 'bout that
rod

(will update first post with latest 1.0.4 pFontselect)

[sunburnt]

Thanks; I`ll redirect somethings(?) to vovchik...

### I think hug.so just being found by the Lib. path is best.

### Perhaps compile hug.so on all the "common" C compilers and versions.
....... Then an installer package to copy the needed one could be written?


# The Linux I`m working to modify with all this is Tiny Core.
It doesn`t use a union, and uses Squash files for app. packages.

But a Debian download GUI is useful to most distros. and certainly Puppy.

I realized years ago that Puppy is one of the few distros. that uses gtkDialog.
So portability with gtkDialog GUIs is never going to be a reality.
BaCon with HUG making exec. files solves this "universal GUI" problem.


I`m beginning to remember how tedious and limited Basic is ( Quick Basic ).
Bash puts it to shame, too bad there isn`t a real free Bash to C Converter.
But for GUIs, use BaCon to support HUG, and use Bash for everything else.

[big_bass]

I think its important we have only a how to link a shared lib nothing else as the focus
step by step using the first example as a reference

even though the first code example was designed to link a shared lib it doesnt

(the app code is great we are only focusing on linking a shared lib during the compile)

and since everyone starts out using a first example it would be good
to use the excellent code and app in the first example thanks to GatorDog
as the practical walk though to linking a shared lib


it is a tricky thing to do so much better if you have some code to
to follow along and test with so that this feature can be used more often

[L18L]

...
one small suggestion to your great app
could you default to the quick brown fox to be in the display by default
...

is existing anywhere, internationalized...
Cheers

[GatorDog]

Big_bass,
Great information! And I will attempt to add a little to it.
Good to know about ldconfig and ldd.

Another way to generate the hug.so/libhug.so
1. Open hug.bac in BaconGUI, Save as: libhug.bac (This takes care of copy/rename).
2. TOOLS/CONVERT/ Check "Create shared object" /CONVERT
3. As suggested above, copy library to a system path, for a standard use /usr/lib.
4. Update linker cache with the linux ldconfig command.

So along with your command line to compile with a link, there are at least
four ways to control compiling a program.
Using this as a small Bacon/hug test program:

Code: Select all

' btest.bac

INCLUDE "/usr/share/BaCon/hug_imports.bac"
' Generates a 51K bytes binary
' ----------------------------------------

'INCLUDE "/usr/share/BaCon/hug_imports_wo_hugso.bac"
' bacon -l hug btest.bac
' Generates a 59k bytes binary
' ----------------------------------------

'INCLUDE "/usr/share/BaCon/hug.bac"
' Generates a 177K bytes binary
' ----------------------------------------

'INCLUDE "/usr/share/BaCon/hug.bac", INIT, WINDOW, ATTACH, BUTTON, CALLBACK, DISPLAY, QUIT
' Generates a 136K bytes binary.
' ----------------------------------------

INIT

Mainwin_ = WINDOW("Bacon Testing", 200, 100)

Ok_btn_ = BUTTON("OK", 100, 30)
ATTACH(Mainwin_, Ok_btn_, 50, 40)
CALLBACK(Ok_btn_, QUIT)

DISPLAY

If you uncomment one "INCLUDE" statement at a time and compile, you can check the size of the resulting binary file.
- For the second method, I made a copy of hug_imports.bac
without the CONST HUG_lib$ = "./libhug.so" statement; since libhug is linked in with
the command: bacon -l hug btest.bac I was surprised to see that it generated a slightly
larger file than compiling without linking. Note- compiling with "bacon -l ..." (linking) was only used with the 2nd example.

The 3rd & 4th examples do not use libhug.so, but instead use hug.bac directly. This is what
I refere to as creating a standalone program. ie. doesn't depend on a libhug.so file being on the target system.
- The third statement, by not selecting specific functions, essentially includes everything
including the ketchen sink; and results in the largest binary.
- The fourth statement generates a significanly smaller binary than the previous (3rd)method.

What's the deal (411/lowdown/story) on the other files reported by "ldd"?
linux-gate.so.1
libm.so.6
libdl.so.2
libhug.so
libc.so.6
/lib/ld-linux.so.2
Are these files that all linux systems need to function? (and therefore sure to be present?)
Or is this one of those maybe but it just depends... kind-of-sort-of things?

still learning,
rod

and what's up with Osama plastering his puss all over everybody's youtube videos?

[BarryK]

# Wouldn`t it be much better if hug.so were in /lib or /usr/lib ? ( in the Lib. path )
This seems all too obvious, but maybe there`s a method to the madness...

In the BaCon PET in the 'common' repo:
http://distro.ibiblio.org/quirky/pet_pa ... 0.23-1.pet
http://distro.ibiblio.org/quirky/pet_pa ... 0.23-1.pet

Does have /usr/lib/hug.so (in the first PET). Most recent puppies are using that PET (Wary, Racy, Slacko), so hug.so is in a "standard" location.

However, it is NOT in the shared library search path. For a start, the shared libraries must be named lib*.so*, otherwise 'ldconfig' (the utility that updates the library search path) ignores it.

Secondly, a BaCon app does not use the shared library load mechanism. It is hard-coded at compile-time to look for hug.so at a particular place.

So, if we all standardize on /usr/lib/hug.so, that would be good.

[GatorDog]

Hi Barry,
Tnx for hug.so info.

Can you shed any light on:

What's the deal (411/lowdown/story) on the other files reported by "ldd" (ref: Bacon binary)?
linux-gate.so.1
libm.so.6
libdl.so.2
libc.so.6
/lib/ld-linux.so.2
Are these files that all linux systems need to function? (and therefore sure to be present?)
Or is this one of those maybe but it just depends... kind-of-sort-of things?

rod

[sunburnt]

GatorDog; This are the base files most all Linux apps. use.

# These 2 are the main Linux "load and function" items as I understand it.
/lib/ld-linux.so.2
linux-gate.so.1

# libc and libm are C related. At least libc is I think...
libc.so.6
libm.so.6

# libdl It appears is used by the larger apps.
libdl.so.2

I`ve written a few scripts to get missing libs and to follow links to the real file.
I`m also in the process of a statistical analysis of lib usage to decide which libs
are used commonly enough to be shared, and uncommon ones to compile in.
The survey sample is about 3500 packages, so it`ll find most libs to be shared.

[big_bass]

everything below the line is copy and paste from the official documentation
all here in blue are just my comments

I hope that Peter the BaCon developer would shed some light on why hug.so isnt
itself a linkable library following the guidelines noted in the documentation
using a lib prefix like the libdemo example (which is the one I followed)

I am still convinced this is the correct way to link a library
but I am unsure now if hug.so itself was meant to be a linkable library
in the same manner

*I havent edited my prior post it can be referenced with the documentation below but I may later to reflect the how to with libdemo instead of libhug.so
using some example code so that we do have a workable practical example for linking a library to follow

here it is with the examples given in the documentation showing the code output

Code: Select all

bacon -f libdemo.bac 

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

Code: Select all

 bacon -l demo program.bac 

Converting 'program.bac'... done.
Compiling 'program.bac'... done.
Program 'program' ready.

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

let's prove if the program runs

Code: Select all

./program

25


the output is 25

everything works
Joe

-------------------------------------------------------------------------
http://www.basic-converter.org/documentation.html

Creating and linking to libraries created with BaCon

With Bacon, it is possible to create libraries. In the world of Unix these are known as shared objects. The following steps should be sufficient to create and link to BaCon libraries.
Step 1: create a library

The below program only contains a function, which accepts one argument and returns a value.

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

In this example the program will be saved as 'libdemo.bac'. Note that the name must begin with the prefix 'lib'. This is a Unix convention. The linker will search for library names starting with these three letters.
Step 2: compile the library

The program must be compiled using the '-f' flag: bacon -f libdemo.bac

This will create a file called 'libdemo.so'.
Step 3: copy library to a system path

To use the library, it must be located in a place which is known to the linker. There are more ways to achieve this. For sake of simplicity, in this example the library will be copied to a system location. It is common usage to copy additional libraries to '/usr/local/lib': sudo cp libdemo.so /usr/local/lib
Step 4: update linker cache

The linker now must become aware that there is a new library. Update the linker cache with the following command: sudo ldconfig
Step 5: demonstration program

The following program uses the function from the new library:

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

This program first declares the function 'bla' as prototype, so the BaCon parser will not choke on this external function. Then the external function is invoked and the result is printed on the screen.
Step 6: compile and link

Now the program must be compiled with reference to the library created before. This can be done as follows: ./bacon -l demo program.bac

With the Unix command 'ldd' it will be visible that the resulting binary indeed has a dependency with the new library!

[sunburnt]

big_bass; Yeah, maybe hug.so can be made into libhug.so and universalized.
Of course it would take some work to Bacon itself to fix how it loads Hug.

# Apparently the canvas can be printed on, but will do multiple lines?

In Visual Basic I made a nice font dialog that printed the font types directly on the Form ( window ).
That way you could see them all at once without repeatedly clicking on them.

# I also need to check out the color dialog to see what it`s like.

[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

[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.?

[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.

rod

[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]

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

[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]

yes!! stop the press

libhug.so can be used and can be linked

mystery solved

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

[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.

[GatorDog]

Well, I don't think there was a coup
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

[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.