Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Tue 21 Oct 2014, 14:19
All times are UTC - 4
 Forum index » Off-Topic Area » Programming
BaCon Bits
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
Page 7 of 12 Posts_count   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 Next
Author Message
big_bass

Joined: 13 Aug 2007
Posts: 1747

PostPosted: Tue 27 Sep 2011, 10:26    Post_subject:  

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:
FUNCTION bla (NUMBER n)
LOCAL i
i = 5 * n
RETURN i
END FUNCTION



call this program.bac

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



let's make the lib using the -f option
Code:
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:
 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:
 ldd /root/bacon-examples/program


Quote:
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:
./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

_________________
debian wheezy ,linux mint, slackware I use them all and they all have good points
Mint would be best for general users though
Back to top
View user's profile Send_private_message 
sunburnt


Joined: 08 Jun 2005
Posts: 5037
Location: Arizona, U.S.A.

PostPosted: Tue 27 Sep 2011, 15:21    Post_subject:  

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.?
Back to top
View user's profile Send_private_message 
GatorDog


Joined: 12 Sep 2006
Posts: 136

PostPosted: Tue 27 Sep 2011, 16:06    Post_subject:  

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:
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:
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:
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. Rolling Eyes

rod

Edited_time_total
Back to top
View user's profile Send_private_message 
GatorDog


Joined: 12 Sep 2006
Posts: 136

PostPosted: Tue 27 Sep 2011, 16:25    Post_subject:  

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 Question

rod
Back to top
View user's profile Send_private_message 
big_bass

Joined: 13 Aug 2007
Posts: 1747

PostPosted: Wed 28 Sep 2011, 23:03    Post_subject:  

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:
 ./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:
 ./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

_________________
debian wheezy ,linux mint, slackware I use them all and they all have good points
Mint would be best for general users though

Edited_time_total
Back to top
View user's profile Send_private_message 
big_bass

Joined: 13 Aug 2007
Posts: 1747

PostPosted: Wed 28 Sep 2011, 23:16    Post_subject:  

Hey rod @GatorDog

Quote:

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

_________________
debian wheezy ,linux mint, slackware I use them all and they all have good points
Mint would be best for general users though
Back to top
View user's profile Send_private_message 
big_bass

Joined: 13 Aug 2007
Posts: 1747

PostPosted: Thu 29 Sep 2011, 11:45    Post_subject:  

yes!! stop the press

libhug.so can be used and can be linked Very Happy

mystery solved Cool

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:
 bacon -f libhug

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


Code:
./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

_________________
debian wheezy ,linux mint, slackware I use them all and they all have good points
Mint would be best for general users though
Back to top
View user's profile Send_private_message 
sunburnt


Joined: 08 Jun 2005
Posts: 5037
Location: Arizona, U.S.A.

PostPosted: Thu 29 Sep 2011, 14:15    Post_subject:  

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.

Edited_time_total
Back to top
View user's profile Send_private_message 
GatorDog


Joined: 12 Sep 2006
Posts: 136

PostPosted: Thu 29 Sep 2011, 20:03    Post_subject:  

Well, I don't think there was a coup Laughing
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:
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
Back to top
View user's profile Send_private_message 
sunburnt


Joined: 08 Jun 2005
Posts: 5037
Location: Arizona, U.S.A.

PostPosted: Thu 29 Sep 2011, 20:45    Post_subject:  

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.
Back to top
View user's profile Send_private_message 
GatorDog


Joined: 12 Sep 2006
Posts: 136

PostPosted: Fri 30 Sep 2011, 00:09    Post_subject:  

Quote:
Once there`s a good copy of libhug.so ...
You already have a copy. Just copy or rename hug.so to libhug.so

Quote:
post a few Bacon app examples showing the init code for it.
You've already been using it. When you use
Code:
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. Rolling Eyes

GatorDog

Saw a good 'make you think' movie on netflix recently, The Encounter
Back to top
View user's profile Send_private_message 
sunburnt


Joined: 08 Jun 2005
Posts: 5037
Location: Arizona, U.S.A.

PostPosted: Fri 30 Sep 2011, 00:58    Post_subject:  

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.?
Back to top
View user's profile Send_private_message 
GatorDog


Joined: 12 Sep 2006
Posts: 136

PostPosted: Fri 30 Sep 2011, 02:15    Post_subject:  

Quote:
# 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

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

Next question? Twisted Evil

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
Back to top
View user's profile Send_private_message 
big_bass

Joined: 13 Aug 2007
Posts: 1747

PostPosted: Fri 30 Sep 2011, 02:25    Post_subject:  

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 Very Happy

Joe
pFontselect-1.0.4-shared.tar.gz
Description 
gz

 Download 
Filename  pFontselect-1.0.4-shared.tar.gz 
Filesize  94.39 KB 
Downloaded  204 Time(s) 

_________________
debian wheezy ,linux mint, slackware I use them all and they all have good points
Mint would be best for general users though
Back to top
View user's profile Send_private_message 
big_bass

Joined: 13 Aug 2007
Posts: 1747

PostPosted: Fri 30 Sep 2011, 09:58    Post_subject:  

GatorDog
Quote:
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

_________________
debian wheezy ,linux mint, slackware I use them all and they all have good points
Mint would be best for general users though
Back to top
View user's profile Send_private_message 
Display_posts:   Sort by:   
Page 7 of 12 Posts_count   Goto page: Previous 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 Next
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
 Forum index » Off-Topic Area » Programming
Jump to:  

Rules_post_cannot
Rules_reply_cannot
Rules_edit_cannot
Rules_delete_cannot
Rules_vote_cannot
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.1316s ][ Queries: 12 (0.0073s) ][ GZIP on ]