|
Post by barryk on Mar 14, 2011 0:27:59 GMT 1
I have been trying to compile a hello world application linked with HUG as a shared library.
I downloaded 'hug_imports.bac', edited it and changed this line:
CONST HUG_lib$ = "libhug.so"
I renamed hug.bac to libhug.bac, then:
# bacon -f libhug.bac Starting conversion... done. Starting compilation... done. Program 'libhug.so' ready. (i copied libhug.so to /usr/lib) # ldconfig # # bacon -l hug hello-gui.bac Starting conversion... done. Starting compilation... done. Program 'hello-gui' ready. # ./hello-gui ERROR: signal for SEGMENTATION FAULT received - memory invalid or array out of bounds? Try to compile the program with TRAP LOCAL to find the cause.
My hello world app:
INCLUDE "hug_imports.bac" INIT
mainwin = WINDOW("Hello World", 400, 50)
label1=MARK("Hello World",350,15) ATTACH(mainwin,label1,58,10)
DISPLAY
Is there anything obvious that I am doing wrong here?
Regards, Barry
|
|
|
Post by Pjot on Mar 14, 2011 7:52:31 GMT 1
Good morning,
it seems to me that you are trying to do two things at once. you are importing functions and also linking with the Shared Object at the same time.
So if you use the 'hug_imports' include file, you do not need to link with the hug.so shared object (therefore you can leave its name unchanged in 'hug_imports'.)
BR, Peter
|
|
|
Post by barryk on Mar 14, 2011 11:47:22 GMT 1
Peter, Thanks for the reply. Yes, you are right, if I leave off the "-l hug" link then it works.
The problem that still remains is that I tried the above after having tried doing it according to the documentation. Previously I had this:
PROTO WINDOW, MARK, ATTACH, DISPLAY, INIT INIT
mainwin = WINDOW("Hello World", 400, 50)
label1=MARK("Hello World",350,15) ATTACH(mainwin,label1,58,10)
DISPLAY
Then link:
# bacon -l hug hello.bac Starting conversion... done. Starting compilation... done. Program 'test2' ready. # ./test2 ERROR: signal for SEGMENTATION FAULT received - memory invalid or array out of bounds? Try to compile the program with TRAP LOCAL to find the cause. #
But anyway, hug_imports.bac now works, so that is fine. What I was aiming to do is reduce the size of the executable, compared with using INCLUDE "hug.bac".
My proxy-setup executable was 115KB, it is now 50KB. That is significant if I write lots of apps with BaCon.
Regards, Barry
|
|
|
Post by barryk on Mar 14, 2011 12:01:30 GMT 1
Peter, There is one line wrong in hug_imports.bac:
IMPORT "FONT(char*,long)" FROM HUG_lib$ TYPE void
Should be:
IMPORT "FONT(long,char*)" FROM HUG_lib$ TYPE void
...reverse them.
Also, I presume NUMBER parameter in
SUB FONT (NUMBER widget, STRING which$)
is C type 'long'.
Regards, Barry
|
|
|
Post by Pjot on Mar 14, 2011 12:57:12 GMT 1
Can you add 'TRAP LOCAL' in the beginning of your program? I bet this will show that the library you have created could not be found, or something like that.
Thanks, you are right, I have corrected it.
The upcoming build22 has the possibility to specify the functions needed to be included. Your program above can be rewritten as follows:
INCLUDE "hug.bac", "WINDOW", "MARK", "ATTACH", "DISPLAY", "INIT"
INIT
mainwin = WINDOW("Hello World", 400, 50)
label1=MARK("Hello World",350,15) ATTACH(mainwin,label1,58,10)
DISPLAY
This also will lead to smaller binaries, with the advantage that you do not need an external HUG library file. Feel free to test it, especially now we're still in beta stage :-)
Best regards Peter
|
|
|
Post by barryk on Mar 15, 2011 0:06:53 GMT 1
Peter, I tried that new technique of appending the HUG names onto the end of INCLUDE "hug.bac", with my proxy-setup program, and ended up with quite a long line and still got errors when try to compile.
I deleted that code, so will have to get back to you later with test results.
Using this new technique, the size of the executable would be bigger than having an external shared library hug.so, wouldn't it?
My proxy-setup stripped executable dropped from 115KB to 50KB by using hug.so, but of course I then have the overhead of hug.so which is 203KB -- but if we end up with lots of BaCon GUI apps in Puppy then that overhead is a good tradeoff.
Regards, Barry
|
|
|
Post by Pjot on Mar 15, 2011 6:59:50 GMT 1
Well, yes, that's true, but then you need the external library also - if you add them up the result will be bigger. Personally I'ld like to have one binary but I guess it is a matter of taste. Regards Peter PS I will be traveling again this week and may not be able to respond very fast.
|
|
|
Post by barryk on Mar 15, 2011 9:42:54 GMT 1
Peter, I was thinking that if we really take to using BaCon and HUG for our code development in Puppy, then say 20 applications all using hug.so, that would be 200K/20 equals 10KB overhead per application.
|
|
|
Post by barryk on Mar 15, 2011 9:55:34 GMT 1
Peter, I have just discovered something. I had a suspicion that it might be the case, so I tested it.
I have /usr/lib/hug.so and I ran 'ldconfig'
I then ran 'ldconfig -p' which lists all cached library files -- hug.so was not there.
I changed the name to libhug.so, then ldconfig did find it and cache it.
So, I will change hug_imports.bac to reference libhug.so, and I will re-upload my BaCon PET package with name change /usr/lib/libhug.so.
|
|
|
Post by Pjot on Mar 16, 2011 3:44:12 GMT 1
You're free to do so, of course; however, this is only needed when you want to link using the '-l' flag with the library. If your program only uses IMPORTS then this is not necessary.
Best regards Peter
|
|
|
Post by Pjot on Mar 17, 2011 13:35:14 GMT 1
Well, I have added the following line in the beginning of your proxy-setup program: INCLUDE "hug.bac", INIT, WINDOW, IMAGE, ATTACH, MARK, CHECK, ENTRY, PASSWORD, TEXT, BUTTON, MSGDIALOG, CALLBACK, QUIT, SET, DISPLAY, HIDE, SHOW, GRAB$, GET, ENABLE, DISABLE, FOCUS
Also you must add INIT to your program before starting to use HUG functions. It works fine then. The size difference on my 64bit system: - Including complete HUG file: 167239 bytes
- Only including the needed functions: 140474 bytes
So with the new functionality the binary gets 16% smaller. Best regards Peter
|
|