I have bben looking for docs for calling X functions to make a window (like the linux equivalent of the win32 api)
However there appears to be no such case I haven't found anything like the Iczelion tutorials or similar. Even Google Linux results lead me to windows code or the AOA site.
Has anyone here used HLA with X ?
briefly, many years ago. i did a simple gui library that works with both windows and x.
documentation was a real pain to find back then, i would imagine it should be easier today?
here it is, maybe it will help you get started.
guilibtest.exe <<< TR/Crypt.XPACK.Gen ; trojan ; Is the Trojan horse TR/Crypt.XPACK.Gen
Please do not provide .EXE (use ZIP and /or Source files if possible) ...
Let's hope that it is a false positive but better safe than sorry.
I can't really help you with HLA aspect as I can't honestly say I've ever used it (read a little about it but couldn't get into the "feel" of it). As for GUI/ASM, I have an X11 demo in my examples.tar.gz file on my homepage and not long ago I wrote a cute little tool called Glade2NASM which lets you design .glade files in the Glade3 editor and have the tool generate a .asm file which does the initialization and sets up your signals. Although both the examples and the code generated by Glade2Nasm are targed for the Netwide Assembler, I would assume that using the HLA documentation you could fairly easily port the code over to HLA. Also, keep in mind when using Glade2Nasm that it was designed as a tool to jumpstart development and I didn't focus much on optimizing so you might think about cleaning up the C source if you plan to port it, it's fairly simplisitic.
Beyond my stuff, once you learn to use LibC from your preferred assembler and design structures, it's just a matter of looking through the libraries documentation and use those skills learned to port the code over. GTK+ and Glade documentation is overly complete and there are literally thousands of examples available on the net. XLib itself is fairly well documented. I do suggest that if you are just starting out, learn XLib first cause it'll introduce you to XEvents and how things work underneath. Later on, you can move on to things like Glade/GTK or wxWidgets if you want something to increase your productivity.
Links
http://assembly.ath.cx/ - For Glade2Nasm and my GNU/Linux Assembly Examples
http://tronche.com/gui/x/xlib/
http://www.unix-manuals.com/tutorials/xlib/xlib.html
http://www.math.msu.su/~vvb/2course/Borisenko/CppProjects/GWindow/xintro.html
http://live.gnome.org/Glade/Tutorials
http://library.gnome.org/devel/gladeui/3.6/
http://www.fifi.org/doc/libgtk1.2-doc/gtk-tutorial-html/gtk_tut.html
http://homepage.mac.com/randyhyde/webster.cs.ucr.edu/HighLevelAsm/HLADoc/HLARef/HLARef_html/HLAReference.htm#50401400_pgfId-998318
Quote from: DarkWolf on January 10, 2011, 09:20:20 PM
I have bben looking for docs for calling X functions to make a window (like the linux equivalent of the win32 api)
However there appears to be no such case I haven't found anything like the Iczelion tutorials or similar. Even Google Linux results lead me to windows code or the AOA site.
Has anyone here used HLA with X ?
The thing with Linux is that X is several layers lower than what the equivlent win32 API would be; what you probably want is the appropriate desktop manager API; if you are writing for Gnome, then google for "GTK", and if you use KDE, look for "QT". Both are built 'on top' of X, so to speak. One of the things to get used to is that GUI applications built for one distro won't necessarily work with another, unlike (most) text-mode applications.
-r
Quote from: redskull on January 11, 2011, 12:04:51 AM
The thing with Linux is that X is several layers lower than what the equivlent win32 API would be; what you probably want is the appropriate desktop manager API; if you are writing for Gnome, then google for "GTK", and if you use KDE, look for "QT". Both are built 'on top' of X, so to speak. One of the things to get used to is that GUI applications built for one distro won't necessarily work with another, unlike (most) text-mode applications.
-r
That's not quite right. You can run GTK apps under KDE and QT apps under Gnome just fine. They just require core dependencies of the other. GTK itself can be ran on Windows, Gnome, KDE, FVMW, etc. Qt has just about the same portability. libgtk and kdelibs are available in just about every repo and can work within other window managers. There is no actual restriction, although I do admit it adds a lot of overhead to your install having both core libraries when only one would suffice.
But yea, like you said, GTK and Qt are built on top of Xlib and are "targeted" towards specific WM's.. kinda like Motif is targeted towards CDE/Mwm but can be used for development on any system which has Motif or Lesstif installed.
Regards,
Bryant Keller
Quote from: Sevag.K on January 10, 2011, 11:28:59 PM
briefly, many years ago. i did a simple gui library that works with both windows and x.
documentation was a real pain to find back then, i would imagine it should be easier today?
here it is, maybe it will help you get started.
That library looks very cool, Sevag - thanks for posting it!
Just a couple of questions -
- The docs mention that khla is required. What is that, and is it still a requirement?
- Is the lib public-domain?
Cheers -
- latte
Gotta love that Linux idea of compatibility: "This is completely compatible with That as long as you separately install and configure the programs to support This alongside that". I remember a time when compatibility meant not having to download something else.
randall has made a gui library called howl for win32, but in the stdlib source code there are folders for howl linux,howl mac, howl freebsd and whatever other computers hla supports. these folders are empty at the moment but i believe he will complete a cross platform howl for all these platforms just like his cross platfrom hla standard library
Linux is modular by design, just like Windows. :U And just like Windows, most apps are going to be built against dynamic libraries. Really, you don't have to install GTK to run a GTK application! Just build your application with the -static option and the parts of GTK that you use are compiled into your application. Same goes for Qt. The reason users tend to build against dynamic libraries is the same reason the Windows API is written as a set of dynamic libraries; updates. Say for example a security flaw is found in GTK, the GTK developers patch this and redistribute, and finally all the users of GTK download this update. Your application, built with the -static option, is still vulnerable. Your users would not only have to download the GTK update, but your software update as well. If you simply link dynamically, you as a developer don't have to worry about updating, that will be taken care on the library side. So yea, it is compatible. Build it on your dev machine with the -static option and copy it over to your KDE box without any GTK libs and it'll run just fine. But as the developer, expect to have to rebuild and release you software each time there is an update to GTK. :wink
Quote from: latte on January 11, 2011, 08:51:25 AM
Quote from: Sevag.K on January 10, 2011, 11:28:59 PM
briefly, many years ago. i did a simple gui library that works with both windows and x.
documentation was a real pain to find back then, i would imagine it should be easier today?
here it is, maybe it will help you get started.
That library looks very cool, Sevag - thanks for posting it!
Just a couple of questions -
- The docs mention that khla is required. What is that, and is it still a requirement?
- Is the lib public-domain?
Cheers -
- latte
khla was abandoned some years ago, it won't even build anymore. for widows, all you need to do is open the project in HIDE and it will build.
for linux, you'll have to write a personal function for the "mem2.fillMem," (unless you want to figure out how to build hidelib.lib on linux!) which is basically a memory zeroing function, get the macros from the HIDE package ( HIDE/hlainc/macros ), and write a makefile to build guilib_events.hla, guilib_frameControl.hla, and root_objects.hla into a library (compile to objects and link to library).
then build guilibtest.hla and link with the library.
it may need further tweaking, i haven't built this on linux for some years now.
the code is public domain.
Hi Sevag - thanks for your reply.
Quote from: Sevag.K
khla was abandoned some years ago, it won't even build anymore. for widows, all you need to do is open the project in HIDE and it will build.
Ok.
Quote from: Sevag.K
for linux, you'll have to write a personal function for the "mem2.fillMem," (unless you want to figure out how to build hidelib.lib on linux!) which is basically a memory zeroing function, get the macros from the HIDE package ( HIDE/hlainc/macros ), and write a makefile to build guilib_events.hla, guilib_frameControl.hla, and root_objects.hla into a library (compile to objects and link to library).
then build guilibtest.hla and link with the library.
it may need further tweaking, i haven't built this on linux for some years now.
Ahh..... sounds like that could take some doing. A bit beyond my ability, I'd say.....
Quote from: Sevag.K
the code is public domain.
Great! Thanks again - bye for now -
- latte
I just got my head bit off on a linux newsgroup for asking this question.
Appearantly you "have" to use all the interevening layers if you want even a simple message box. Nevermind the fact that X has a function XCreateSimpleWindow();
He was saying how you have to use all the wrappers (GTK/QT/Gnome/KDE) and libraries (TCL/TK/X/Whatever) and then went on about the different arch types.
Oh well, looks like you may have to use Perl and Python yet (PyQT). Can't keep nothing simple can we.
I need to learn to stop asking questions that rock the fundemental foundation upon which all things are developed.
Any way I have tried compiling the hidelib on linux before but it never worked because it kept giving me errors that something was undefined.
I hadn't tried with the most recent version, I downloaded another copy a little ago but hadn't tried yet.
mem2.fillMem function is in the library right ? so get hidelib to compile and then we wouldn't have to rewrite that function ?
Hidelib doesn't have anything windows speciifc does it ? I think the problem I always have in trying to compile is that either HLA can't find the necessary headers (maybe cause linux is case sensitive) or that there is a difference between the headers and the source.
HOWL for the other versions of HLA would be nice but I don't expect that anytime soon ( like 64bit support :P ) Randall doesn't release anything till it's how he wants it or it is working correctly and I wish some Linux devs had that attitude.
I was thinking how it would be easier (in the long run) if wForm was wrapped inside an object called uiForm which would be wForm on winodws as it is now; xForm for Linux/BSD and aForm for MacOS (Aqua is default right ? X needs installed on Macs) That way like HLA is now HOWL could be supported on multiple platforms with just a recompile.
Hi DarkWolf -
Quote from: DarkWolf
I just got my head bit off on a linux newsgroup for asking this question.
Appearantly you "have" to use all the interevening layers if you want even a simple message box. Nevermind the fact that X has a function XCreateSimpleWindow();
That's unfortunate, ay. There's no need for the person in that newsgroup to be aggressive.
Quote from: DarkWolf
He was saying how you have to use all the wrappers (GTK/QT/Gnome/KDE) and libraries (TCL/TK/X/Whatever) and then went on about the different arch types.
Oh well, looks like you may have to use Perl and Python yet (PyQT). Can't keep nothing simple can we.
Yeah - so it seems! Actually, although I'm still very much a newbie at asm coding, I'm beginning to like it.
When you're coding in such a low-level language, there's nothing to get in the way.
Quote from: DarkWolf
I need to learn to stop asking questions that rock the fundemental foundation upon which all things are developed.
Well..... maybe put on a fireproof suit.... ;)
Quote from: DarkWolf
Any way I have tried compiling the hidelib on linux before but it never worked because it kept giving me errors that something was undefined.
Ah.... ok. That's a pity.
Yeah - what I would *love* to find somewhere is a simple public-domain example of Linux GUI coding in assembly. There seem to be very few of them around. The two things I want to be able to do most are -
a) How to create a window (preferably with window controls on it - maximise and close)
b) How to create menus in that window.
My preference is to be able to do this using only public-domain code (I don;t know if hidelib is P.D. - I think it is freeware). Anyway, I think it may be possible using HLA itself and nothing else.
- latte
Quote
I thought I have seen in the about dialog in HIDE that sevag states HIDE is PD (don't quote me I haven't fired my windows machine in a while and HIDE doesn't run under WINE). I would assume that means the lib is also PD. But I don't recall what the source code says if at all (I usually put that in my source)
Nevermind looked into archive I had; it is freeware.
For a) and b) (which is the only docs I have yet to find) :
http://tronche.com/gui/x/
With this very encouraging tutorial :
http://tronche.com/gui/x/xlib-tutorial/
In short you :
1. open client/server connection
2. create window
3. map window to screen
4. display window to screen
5. Have window do something or sleep for a few seconds (X doesn't like a window that doesn't do anything)
6. When done destroy window
7. close client/server connection
Still not sure where GTK/others fit here.
HIDE is released as copyrighted opensource freeware (cannot released under a different license)
HIDELIB is public domain opensource.
Quote from: DarkWolf on January 14, 2011, 08:56:54 PM
Any way I have tried compiling the hidelib on linux before but it never worked because it kept giving me errors that something was undefined.
i used to have a working makefile, but it got crashed with my old computer.
Quote
I hadn't tried with the most recent version, I downloaded another copy a little ago but hadn't tried yet.
mem2.fillMem function is in the library right ? so get hidelib to compile and then we wouldn't have to rewrite that function ?
correct, but mem2.fillMem is a simple function, a few lines, you don't have to go through the hassle of rebuilding the entire library just for that.
procedure mem2.fillMem (var lpSource:dword; MemSize:dword; Value:byte );
@noframe; @nodisplay; @noalignstack;
begin fillMem;
push( ebp );
mov( esp, ebp );
push( eax );
push( edi );
push( ecx );
cld();
mov( lpSource, edi );
mov( MemSize, ecx );
mov( Value, al );
rep.stosb();
pop( ecx );
pop( edi );
pop( eax );
pop( ebp );
ret( _parms_ );
end fillMem;
Quote
Hidelib doesn't have anything windows speciifc does it ? I think the problem I always have in trying to compile is that either HLA can't find the necessary headers (maybe cause linux is case sensitive) or that there is a difference between the headers and the source.
no windows specific code. it just uses hlalib and other hidelib functions. it needs the macros and headers from the HIDE package, expecting them to be on your %hlainc%/hide and %hlainc%/macros paths. but the headers are also in the src directory of hidelib project, they just need to be copied to the correct paths above.
Quote
HOWL for the other versions of HLA would be nice but I don't expect that anytime soon ( like 64bit support :P ) Randall doesn't release anything till it's how he wants it or it is working correctly and I wish some Linux devs had that attitude.
I was thinking how it would be easier (in the long run) if wForm was wrapped inside an object called uiForm which would be wForm on winodws as it is now; xForm for Linux/BSD and aForm for MacOS (Aqua is default right ? X needs installed on Macs) That way like HLA is now HOWL could be supported on multiple platforms with just a recompile.
i think the idea is to have it cross platform in the future, it's just that linux gui programming is arsed compared to windows, especially when starting from scratch. that's the main reason i abandoned work on guilib... it took me several days of searching and asking just to figure out how interrupt a close button click on a window.
Quote from: Sevag.K on January 14, 2011, 10:48:08 PM
HIDE is released as copyrighted opensource freeware (cannot released under a different license)
HIDELIB is public domain opensource.
Hi Sevag -
Thanks very much for clarifying that - that's great!
Interesting that you mention that Linux GUI programming is, umm, "arsed"... :wink
I'm a bit of a fan of the Plan 9 OS. Apparently in that, everything is treated as a file (Unix and Linux do that to a certain extent, but Plan 9 goes all the way). Anyway, if Linux had used that approach to things, I wonder if that would have made things easier as far as GUI coding goes? It would seem to, but I'm not an expert.
- latte
i'm not familiar with plan 9 OS. sounds like a B movie.
the biggest problem with linux gui is that it was added in as an afterthought and everybody added their own bit to it as the years went by.
while i like gui "skins" and customizations, i'm no fan of different implementations. there should be only one, well documented graphics kernel. in this one thing probably the opensource bit was not such a good idea for linux.
Quote from: Sevag.K
i'm not familiar with plan 9 OS. sounds like a B movie.
In fact, you're exactly right - that *is* what it is named after. A move called "Plan 9 from Outer Space", by Ed Wood. It is widely regarded as the worst movie ever made.
http://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs
Quote from: Sevag.K
the biggest problem with linux gui is that it was added in as an afterthought and everybody added their own bit to it as the years went by.
Ok. Yes, that'd mean that the gui would end up as a real mish-mash. No good long-term planning and design.
Quote from: Sevag.K
while i like gui "skins" and customizations, i'm no fan of different implementations. there should be only one, well documented graphics kernel. in this one thing probably the opensource bit was not such a good idea for linux.
Ok.
- latte
Yes building the hidelib for one function may be over kill but not if I also make use of other functions as well.
I had to correct for case sensitivity (all lower case filenames work)
But I still end up with some errors in class_list_remove.hla
$ hla -c src/*.hla
Error in file "src/class_list_remove.hla" at line 25 [errid:38698/hlaparse.bsn]:
Identifier "node_t" must be identical to declaration "lNode".
Near: << ) >>
Error in file "src/class_list_remove.hla" at line 25 [errid:24125/hlaparse.bsn]:
This class method has not been overridden.
Near: << ) >>
Error in file "src/class_list_remove.hla" at line 34 [errid:128231/hlaparse.c]:
syntax error, unexpected ',', expecting ':' or '.'.
Near: << , >>
HLAPARSE assembly failed with 3 errors
And it's not that GUI programming "would end up" as mish mash; it "*did* end up" as mish mash.
The fact we need four layers and three toolkits means someone needs to go back and rewrite X but I guess it's too late for that.
Quote from: DarkWolf on January 16, 2011, 12:58:51 AM
Yes building the hidelib for one function may be over kill but not if I also make use of other functions as well.
I had to correct for case sensitivity (all lower case filenames work)
But I still end up with some errors in class_list_remove.hla
$ hla -c src/*.hla
Error in file "src/class_list_remove.hla" at line 25 [errid:38698/hlaparse.bsn]:
Identifier "node_t" must be identical to declaration "lNode".
Near: << ) >>
Error in file "src/class_list_remove.hla" at line 25 [errid:24125/hlaparse.bsn]:
This class method has not been overridden.
Near: << ) >>
Error in file "src/class_list_remove.hla" at line 34 [errid:128231/hlaparse.c]:
syntax error, unexpected ',', expecting ':' or '.'.
Near: << , >>
HLAPARSE assembly failed with 3 errors
oops, legacy code, just delete that file. i've just done it on my end. the remove method for tList moved to the superclass tBaseList several versions ago.
Quote
And it's not that GUI programming "would end up" as mish mash; it "*did* end up" as mish mash.
The fact we need four layers and three toolkits means someone needs to go back and rewrite X but I guess it's too late for that.
yup. the mac is beginning to look like a good option as this point. alas, i don't have the hardware cohones to build a mac-box and anything with an apple sticker on it is $500 overpriced.
Quote from: Sevag.K on January 15, 2011, 03:11:01 AM
while i like gui "skins" and customizations, i'm no fan of different implementations. there should be only one, well documented graphics kernel. in this one thing probably the opensource bit was not such a good idea for linux.
you mean stuffs like GTK, Qt, etc?
probably the solution is to write ASM wrappers which could cope them all, like LCL (Lazarus Component Library)
it works well with GTK1, GTK2, Qt, Cocoa, etc
Quote from: TmX on January 16, 2011, 01:40:35 PM
Quote from: Sevag.K on January 15, 2011, 03:11:01 AM
while i like gui "skins" and customizations, i'm no fan of different implementations. there should be only one, well documented graphics kernel. in this one thing probably the opensource bit was not such a good idea for linux.
you mean stuffs like GTK, Qt, etc?
probably the solution is to write ASM wrappers which could cope them all, like LCL (Lazarus Component Library)
it works well with GTK1, GTK2, Qt, Cocoa, etc
No, I think the move should be to use OpenGL with X.
Use X to handle the window process and Opengl for graphics.
There was somewhere I saw a tutorial for that.
The problem is that OpenGL is still a complicated beast for something simple.
The example I saw turned a twenty line code in to almost 50. A 100% increase for just one intrepeted layer.
Sevag's GUILIB idea was propably spot on.
Quote from: Sevag.K on January 16, 2011, 03:04:26 AM
oops, legacy code, just delete that file. i've just done it on my end. the remove method for tList moved to the superclass tBaseList several versions ago.
You mean "src/class_list_remove.hla" right ? My download wasn't that old. The whole file is not used ?
Quote
yup. the mac is beginning to look like a good option as this point. alas, i don't have the hardware cohones to build a mac-box and anything with an apple sticker on it is $500 overpriced.
Even if you could build a "mac" box. You can't buy the OS it only comes with the hardware (as far as I know). It's a package deal.
Quote from: DarkWolf on January 22, 2011, 10:05:49 PM
Quote from: Sevag.K on January 16, 2011, 03:04:26 AM
oops, legacy code, just delete that file. i've just done it on my end. the remove method for tList moved to the superclass tBaseList several versions ago.
You mean "src/class_list_remove.hla" right ? My download wasn't that old. The whole file is not used ?
yes, the entire file is not used. delete it no problem.
It's probably been there for a while, but since HIDE has a built in make file in the .hpr, i removed it from the .hpr but forgot to delete it from the drive (actually HIDE was supposed to delete it when i removed it from the project, but there must have been a bug that prevented this).
this is the pseudo make list for the project as it stands in the latest version
version 1.72.03
hidelib.lib
hidefunc.lib
scan.lib
class.lib
bufferclass.lib
configclass.lib
strbuffer.lib
listclass.lib
hidefunc.lib
src/env2_envunit.hla
src/hide_data.hla
src/hide_info.hla
src/hide_putmem.hla
src/hide_putn.hla
src/hide_putz.hla
src/hide_stricmp.hla
src/mem2_size.hla
src/os2_getmodulepath.hla
src/os2_sysexec.hla
scan.lib
src_scanlib/scan_extract.hla
src_scanlib/scan_find.hla
src_scanlib/scan_findc.hla
src_scanlib/scan_ifind.hla
src_scanlib/scan_imatch.hla
src_scanlib/scan_imatchword.hla
src_scanlib/scan_irfind.hla
src_scanlib/scan_lines.hla
src_scanlib/scan_match.hla
src_scanlib/scan_matchword.hla
src_scanlib/scan_pfind.hla
src_scanlib/scan_rfind.hla
src_scanlib/scan_skipalphanum.hla
src_scanlib/scan_skipws.hla
src_scanlib/scan_tokens.hla
class.lib
src/class_clone.hla
src/class_stack.hla
bufferclass.lib
src_class_buf/class_buf.hla
src_class_buf/class_buf_bof.hla
src_class_buf/class_buf_delete.hla
src_class_buf/class_buf_eof.hla
src_class_buf/class_buf_eq.hla
src_class_buf/class_buf_getindex.hla
src_class_buf/class_buf_ieq.hla
src_class_buf/class_buf_iseof.hla
src_class_buf/class_buf_left.hla
src_class_buf/class_buf_moveto.hla
src_class_buf/class_buf_putb.hla
src_class_buf/class_buf_putbuffer.hla
src_class_buf/class_buf_putd.hla
src_class_buf/class_buf_putfile.hla
src_class_buf/class_buf_putl.hla
src_class_buf/class_buf_putq.hla
src_class_buf/class_buf_puts.hla
src_class_buf/class_buf_putw.hla
src_class_buf/class_buf_right.hla
src_class_buf/class_buf_sub.hla
src_class_buf/class_buf_substring.hla
src_class_buf/class_buf_write.hla
src_class_buf/class_buffer.hla
src_class_buf/class_buffer_block.hla
src_class_buf/class_buffer_cmp.hla
src_class_buf/class_buffer_cursor.hla
src_class_buf/class_buffer_del.hla
src_class_buf/class_buffer_extract.hla
src_class_buf/class_buffer_info.hla
src_class_buf/class_buffer_insert.hla
src_class_buf/class_buffer_line.hla
src_class_buf/class_buffer_lineword.hla
src_class_buf/class_buffer_match.hla
src_class_buf/class_buffer_misc.hla
src_class_buf/class_buffer_out.hla
src_class_buf/class_buffer_read.hla
src_class_buf/class_buffer_replace.hla
src_class_buf/class_buffer_search.hla
src_class_buf/class_buffer_searchr.hla
src_class_buf/class_buffer_token.hla
src_class_buf/class_bufferbase.hla
configclass.lib
src_class_config/class_config.hla
src_class_config/class_config_bool.hla
src_class_config/class_config_cpysec.hla
src_class_config/class_config_del.hla
src_class_config/class_config_hex.hla
src_class_config/class_config_int.hla
src_class_config/class_config_item.hla
src_class_config/class_config_itemtokens.hla
src_class_config/class_config_real.hla
src_class_config/class_config_rename.hla
src_class_config/class_config_sections.hla
src_class_config/class_config_strings.hla
src_class_config/class_config_uns.hla
strbuffer.lib
src/class_strbuffer.hla
src/class_strbuffer_get.hla
src/class_strbuffer_info.hla
src/class_strbuffer_put.hla
listclass.lib
src/class_baselist.hla
src/class_baselist_node.hla
src/class_baselist_utils.hla
src/class_flist.hla
src/class_flist_find.hla
src/class_flist_funcs.hla
src/class_flist_remove.hla
src/class_list.hla
src/class_list_find.hla
src/class_list_set.hla
any file that's not in this list is not a part of the project.
Quote
Even if you could build a "mac" box. You can't buy the OS it only comes with the hardware (as far as I know). It's a package deal.
you can buy the os and install it on hardware built up from scratch. there are some tutorials for doing this online, but my skill with hardware stops at installing memory.
Quote
Quote from: DarkWolf
(snip)
And it's not that GUI programming "would end up" as mish mash; it "*did* end up" as mish mash.
Agreed! Yes, it makes one wonder how on earth it all got so complicated.
Quote from: DarkWolf
The fact we need four layers and three toolkits means someone needs to go back and rewrite X but I guess it's too late for that.
Yes, also agreed.
How on earth people can say that X is the best thing since sliced bread is beyond me... :)
- latte
- sevag -
I had not realized that hidelib was made up of other libs.
The linux iinstructions in the package indicates a "flat" library.
Does archivers (as in library porgrams like ar) merge these or can one make a "tree" of library files in one lib file.
( Or is the make file that way just to maintain the library ? )
- latte -
If I understand how it works coorectly.
The original guilib executable from sevag zip file uses only X api functions.
But if I run it beside a GTK or Qt app, you won't notice a difference because the theming is handled by my Gnome Desktop.
Why anyone would bite my head off in a linux newsgroup when I asked for more tutorials on how to do this is beyond me.
Aside from the lack of resources/icons can anyone spot the difference between an X and GTK app ?
src/class_baselist_node.hla does not to appear to exist in the hidelib.zip archive and you don't list it in your kmake file.
( Please ignore my logging; it's how I do things :P )
I tried to emulate your kmake file in a makefile.
Results :
$ make hidelib.a
date -u +%F_%T >> log/build.log
hla -c src/env2_envunit.hla >> log/build.log
hla -c src/hide_data.hla >> log/build.log
hla -c src/hide_info.hla >> log/build.log
hla -c src/hide_putmem.hla >> log/build.log
hla -c src/hide_putn.hla >> log/build.log
hla -c src/hide_putz.hla >> log/build.log
hla -c src/hide_stricmp.hla >> log/build.log
hla -c src/mem2_size.hla >> log/build.log
hla -c src/os2_getmodulepath.hla >> log/build.log
Error in file "src/os2_getmodulepath.hla" at line 36 [errid:27596/output.c]:
Parameter type mismatch (zstr).
Near: << , >>
It has a problem with str.cpyz maybe ?
HLAPARSE assembly failed with 1 errors
hla -c src/os2_sysexec.hla >> log/build.log
Error in file "src/os2_sysexec.hla" at line 102 [errid:77411/hlaparse.bsn]:
Expected ':', encountered '('
(Possible undefined ID '.tokenize2').
Near: << ( >>
There doesn't appear to be a str.tokenize2 func is this supposed to be tokenize4 or tokenize3 ?
HLAPARSE assembly failed with 1 errors
ar -vr hidefunc.a src/env2_envunit.hla >> log/build.log
ar: creating hidefunc.a
ar -vr hidefunc.a src/hide_data.hla >> log/build.log
ar -vr hidefunc.a src/hide_info.hla >> log/build.log
ar -vr hidefunc.a src/hide_putmem.hla >> log/build.log
ar -vr hidefunc.a src/hide_putn.hla >> log/build.log
ar -vr hidefunc.a src/hide_putz.hla >> log/build.log
ar -vr hidefunc.a src/hide_stricmp.hla >> log/build.log
ar -vr hidefunc.a src/mem2_size.hla >> log/build.log
ar -vr hidefunc.a src/os2_getmodulepath.hla >> log/build.log
ar -vr hidefunc.a src/os2_sysexec.hla >> log/build.log
date -u +%F_%T >> log/build.log
hla -c src_scanlib/*.hla >> log/build.log
ar -vr scan.a src_scanlib/*.o >> log/build.log
ar: creating scan.a
date -u +%F_%T >> log/build.log
hla -c src/class_clone.hla >> log/build.log
Error in file "/media/data/Programming/asm/include/hide/classlib.hhf" at line 42 [errid:128231/hlaparse.c]:
syntax error, unexpected typeTkn.
Near: << type >>
Ignore I just realized my makefile had me adding hla files to the library file (doh!)
Error in file "/media/data/Programming/asm/include/hide/classlib.hhf" at line 47 [errid:128231/hlaparse.c]:
syntax error, unexpected endrecordTkn.
Near: << endrecord >>
HLAPARSE assembly failed with 2 errors
hla -c src/class_stack.hla >> log/build.log
Error in file "/media/data/Programming/asm/include/hide/classlib.hhf" at line 42 [errid:128231/hlaparse.c]:
syntax error, unexpected typeTkn.
Near: << type >>
Error in file "/media/data/Programming/asm/include/hide/classlib.hhf" at line 47 [errid:128231/hlaparse.c]:
syntax error, unexpected endrecordTkn.
Near: << endrecord >>
?? I was going to ask about the record but I also noticed that you declare a type section inside a class; I thought that was forbidden ??
But you seem to do that in several places but only this one instance gets flagged.
Now that I fixed the commands to not add the hla files to the library this error disappears ??
HLAPARSE assembly failed with 2 errors
ar -vr class.a src/class_clone.o src/class_stack.o >> log/build.log
ar: creating class.a
ar: src/class_clone.o: No such file or directory
make: *** [class.a] Error 1
Ignore this; failed since the object files couldn't be built.
Quote from: DarkWolf on January 24, 2011, 07:30:33 PM
- sevag -
I had not realized that hidelib was made up of other libs.
The linux iinstructions in the package indicates a "flat" library.
Does archivers (as in library porgrams like ar) merge these or can one make a "tree" of library files in one lib file.
( Or is the make file that way just to maintain the library ? )
i set it up into different libraries for maintenance reasons. lib/link on windows can combine them into one contiguous library. i don't know how ar works, but you don't have to build separate libraries at all. one flat library will work just fine.
Quote
- latte -
If I understand how it works coorectly.
The original guilib executable from sevag zip file uses only X api functions.
But if I run it beside a GTK or Qt app, you won't notice a difference because the theming is handled by my Gnome Desktop.
that is the way it should function. in the original when i had "khla" (now discontinued) to build it, only x-lib was linked in. i believe i was working under a kde environment at that time. so the only difference you would notice is the way the window borders/title are drawn.
Quote
Why anyone would bite my head off in a linux newsgroup when I asked for more tutorials on how to do this is beyond me.
elitism.
Quote
Aside from the lack of resources/icons can anyone spot the difference between an X and GTK app ?
gtk (or whatever tookit you're using) draws the border, title and widgets on the window and handles and sends messages through X messages to the parent program where they are either handled or ignored. to see which messages guilib intercepts, look at the messageLoop procedure in "guilib_frameControl.hla"
the 'X' part you're seeing is just the basic 'frame' which is the part flooded with the background color.
i wanted to get a proof of theory out asap and planned on writing the window control with the button widgets later. but like i said, i got frustrated trying to find help documents on how to do all that stuff so i just gave up and moved on to greener pastures...windows.
Quote from: DarkWolf on January 24, 2011, 09:49:15 PM
src/class_baselist_node.hla does not to appear to exist in the hidelib.zip archive and you don't list it in your kmake file.
oops, i just added that recently and haven't uploaded it yet. this is the src/classlist_node.hla file:
unit class_baselist_node_unit;
#includeonce ("hide/hidelib.hhf")
?@nodisplay := true;
?@noalignstack := true;
const
nodeeax :text := "(type tBaseList.baseNode[eax])";
proc
tBaseList.nodes :iterator;
begin nodes;
USE( EAX );
mov( this.head, eax );
while( eax ) do
push( eax );
yield();
pop( eax );
mov( nodeeax.next, eax );
endwhile;
ENDUSE;
end nodes;
end class_baselist_node_unit;
it you want to include it, you'll have to add it to the header file too. i thought an iterator would be handy since i constantly cycle through all the objects of a list in my programs.
i'll upload the updated library later today when i get a chance.
Quote
( Please ignore my logging; it's how I do things :P )
I tried to emulate your kmake file in a makefile.
Results :
$ make hidelib.a
date -u +%F_%T >> log/build.log
hla -c src/env2_envunit.hla >> log/build.log
hla -c src/hide_data.hla >> log/build.log
hla -c src/hide_info.hla >> log/build.log
hla -c src/hide_putmem.hla >> log/build.log
hla -c src/hide_putn.hla >> log/build.log
hla -c src/hide_putz.hla >> log/build.log
hla -c src/hide_stricmp.hla >> log/build.log
hla -c src/mem2_size.hla >> log/build.log
hla -c src/os2_getmodulepath.hla >> log/build.log
Error in file "src/os2_getmodulepath.hla" at line 36 [errid:27596/output.c]:
Parameter type mismatch (zstr).
Near: << , >>
It has a problem with str.cpyz maybe ?
you'll have to account for some changes in the hla stdlib since the library was written. it's a type casting issue.
change to code to:
str.cpyz( lea( eax, buffer ), dest );
Quote
HLAPARSE assembly failed with 1 errors
hla -c src/os2_sysexec.hla >> log/build.log
Error in file "src/os2_sysexec.hla" at line 102 [errid:77411/hlaparse.bsn]:
Expected ':', encountered '('
(Possible undefined ID '.tokenize2').
Near: << ( >>
There doesn't appear to be a str.tokenize2 func is this supposed to be tokenize4 or tokenize3 ?
that's a tricky one, but you can probably keep it out of the library since the stdlib has a system command now (but it works a bit differently than mine).
i think you have to use tokenize4 now:
tokenize4:
procedure
(
src: string;
delims: cset;
var dest: var;
maxStrs: dword
) {@returns( "eax" )};
@global:_hla._ext( "STR_TOKENIZE4" );
this might work:
str.tokenize4( cmdLn, { ' ', ',' }, cmds, 256 );
Quote
?? I was going to ask about the record but I also noticed that you declare a type section inside a class; I thought that was forbidden ??
But you seem to do that in several places but only this one instance gets flagged.
Now that I fixed the commands to not add the hla files to the library this error disappears ??
as of hla 2.15, type sections are allowed in a class as long as you don't try to type a nested class. it's still fairly new so errors might crop up. i've had no problems on the windows end.
I think I still have 2.14 not sure because the linux version still reports itself as 2.13
Quote
that's a tricky one, but you can probably keep it out of the library since the stdlib has a system command now (but it works a bit differently than mine).
Just the os2_sysexec file or all the os2 files; which relates to your version of the system command.
I am having power issues with a local snow storm so I'll look at your website later.
Quote from: Sevag.K on January 24, 2011, 09:52:48 PM
elitism.
Quote
i wanted to get a proof of theory out asap and planned on writing the window control with the button widgets later. but like i said, i got frustrated trying to find help documents on how to do all that stuff so i just gave up and moved on to greener pastures...windows.
Yes, I know.
They cry community, then don't want to play nice. (See my posts in --hutch's wikipedia thread)
The thing is the user in question in the linux newsgroup was normally helpful in the past. Guess I hit the right button this time.
Documentation is one thing that Linux devs do not do well.
Quote from: DarkWolf on January 27, 2011, 04:31:51 AM
I think I still have 2.14 not sure because the linux version still reports itself as 2.13
i just uploaded v1.72.04
you will need hla v2.15+ to build it.
Quote
Just the os2_sysexec file or all the os2 files; which relates to your version of the system command.
only os2_sysexec relates to my version of system command.
though you may consider keeping it in and testing if the changes i made work, as far as the last time i built the library on linux myself (over a year ago), my os2.sysexec had better path-finding code (on linux) than the hlalib os.system version. that may or may not have changed since.
the other function in my os2 namespace, getmodulepath does not have an hlalib counterpart.
(Long ass post; bear with me :P )
Makefile in use
hidelib_dep= src/*.hla
hla_lib= /media/data/Programming/asm/hlalib
hidelib.a: $(hidelib_dep)
date -u +%F_%T >> log/build.log
hla -vc src/*.hla >> log/build.log
ar -qvc hidelib.a src/*.o >> log/build.log
ar -vs hidelib.a >> log/build.log
install:
cp hidelib.a $(hla_lib)/hide
# EOL
Assembling "src/os2_sysexec.hla" to "src/os2_sysexec.o"
Error in file "src/os2_sysexec.hla" at line 117 [errid:77784/hlaparse.bsn]:
Expected ':', encountered '('
(Possible undefined ID '.exists').
Near: << ( >>
HLAPARSE assembly failed with 1 errors
fo.hla"]
src/os2_sysexec.hla; line 117
// file not found. look for PATH environment.
str.talloc (5000);
mov (eax, pathVar);
str.talloc (2000);
mov (eax, binName);
str.cpy (cmds[0], binName);
filesys.exists (binName); //<--- you originally had fileio.exists (stdlib has no function I can find)
cmp (eax, true);
je _runit;
(even after correcting it still does not compile on linux, since you said that os2_sysexec.hla can be ignored I will but I thought to still tell you of the error)
Oddly linux hla still calls ld even though I specified -vc options:
$ make hidelib.a >> log/build.log
ld: warning: cannot find entry symbol _start; defaulting to 0000000008048074
src/env2_envunit.o: In function `ENV2_GETENVSTRINGS':
(.text+0x1): undefined reference to `_envp__hla_'
src/env2_envunit.o: In function `ENV2_GET':
(.text+0x2b): undefined reference to `_envp__hla_'
src/env2_envunit.o: In function `endif__hla_806':
(.text+0xe5): undefined reference to `_envp__hla_'
src/env2_envunit.o: In function `false__hla_815':
(.text+0x19e): undefined reference to `_envp__hla_'
src/env2_envunit.o: In function `false__hla_817':
(.text+0x1be): undefined reference to `_envp__hla_'
src/env2_envunit.o:(.text+0x1e5): more undefined references to `_envp__hla_' follow
/media/data/Programming/asm/hlalib/hlalib.a(ex_buildexcepts.o): In function `BuildExcepts__hla_':
(.text+0x1): undefined reference to `InstallSignals__hla_'
/media/data/Programming/asm/hlalib/hlalib.a(ex_buildexcepts.o): In function `BuildExcepts__hla_':
(.text+0x7): undefined reference to `DfltExHndlr__hla_'
/media/data/Programming/asm/hlalib/hlalib.a(ex_buildexcepts.o): In function `MainPgmCoroutineVMT__hla_80':
(.text+0x28): undefined reference to `QuitMain__hla_'
ar: no operation specified
make: *** [hidelib.a] Error 1
aside from src/os2_sysexec this is the hidelib.a listing after compile
a - src/class_baselist_node.o
a - src/class_baselist.o
a - src/class_baselist_utils.o
a - src/class_buf_bof.o
a - src/class_buf_delete.o
a - src/class_buf_eof.o
a - src/class_buf_eq.o
a - src/class_bufferbase.o
a - src/class_buffer_block.o
a - src/class_buffer_cmp.o
a - src/class_buffer_cursor.o
a - src/class_buffer_del.o
a - src/class_buffer_extract.o
a - src/class_buffer_info.o
a - src/class_buffer_insert.o
a - src/class_buffer_line.o
a - src/class_buffer_lineword.o
a - src/class_buffer_match.o
a - src/class_buffer_misc.o
a - src/class_buffer.o
a - src/class_buffer_out.o
a - src/class_buffer_read.o
a - src/class_buffer_replace.o
a - src/class_buffer_search.o
a - src/class_buffer_searchr.o
a - src/class_buffer_token.o
a - src/class_buf_getindex.o
a - src/class_buf_ieq.o
a - src/class_buf_iseof.o
a - src/class_buf_left.o
a - src/class_buf_moveto.o
a - src/class_buf.o
a - src/class_buf_putb.o
a - src/class_buf_putbuffer.o
a - src/class_buf_putd.o
a - src/class_buf_putfile.o
a - src/class_buf_putl.o
a - src/class_buf_putq.o
a - src/class_buf_puts.o
a - src/class_buf_putw.o
a - src/class_buf_right.o
a - src/class_buf_sub.o
a - src/class_buf_substring.o
a - src/class_buf_write.o
a - src/class_clone.o
a - src/class_config_bool.o
a - src/class_config_cpysec.o
a - src/class_config_del.o
a - src/class_config_hex.o
a - src/class_config_int.o
a - src/class_config_item.o
a - src/class_config_itemtokens.o
a - src/class_config.o
a - src/class_config_real.o
a - src/class_config_rename.o
a - src/class_config_sections.o
a - src/class_config_strings.o
a - src/class_config_uns.o
a - src/class_flist_find.o
a - src/class_flist_funcs.o
a - src/class_flist.o
a - src/class_flist_remove.o
a - src/class_list_find.o
a - src/class_list.o
a - src/class_list_set.o
a - src/class_stack.o
a - src/class_strbuffer_get.o
a - src/class_strbuffer_info.o
a - src/class_strbuffer.o
a - src/class_strbuffer_put.o
a - src/env2_envunit.o
a - src/hide_data.o
a - src/hide_info.o
a - src/hide_putmem.o
a - src/hide_putn.o
a - src/hide_putz.o
a - src/hide_stricmp.o
a - src/mem2_size.o
a - src/os2_getmodulepath.o
a - src/scan_extract.o
a - src/scan_findc.o
a - src/scan_find.o
a - src/scan_ifind.o
a - src/scan_imatch.o
a - src/scan_imatchword.o
a - src/scan_irfind.o
a - src/scan_lines.o
a - src/scan_match.o
a - src/scan_matchword.o
a - src/scan_pfind.o
a - src/scan_rfind.o
a - src/scan_skipalphanum.o
a - src/scan_skipws.o
a - src/scan_tokens.o
test apps (okay you warned they were out of date in the source but I thought to give them a try)
Error in file "hidelibtest.hla" at line 61 [errid:81732/hlaparse.bsn]:
Error in file "hidelibtest.hla" at line 72 [errid:77784/hlaparse.bsn]:
hide.extract and hide.scanf (I tried replacing hide.extract with scan.extract which looked similar but they must be different enough. Found no replacement for scanf)
Error in file "hidelibtest2.hla" at line 110 [errid:11027/hlaparse.bsn]:
Error in file "hidelibtest2.hla" at line 133 [errid:77784/hlaparse.bsn]:
baseNode_t and func.FillMemory (this also applies to test/hidelib.hla which is the same file)
Testlib.hla was a windows app so I didn't try that one.
I tried to keep os2_sysexec but it still had issues. There is no fileio.exists and filesys.exists won't work. Wrong parameter or something I didn't work at that one too hard since it was possible to build with out that file.
Linux version attached if any one is brave to try.
I am going to try kmake and guilib next.
Quote from: DarkWolf on February 02, 2011, 12:54:51 AM
Assembling "src/os2_sysexec.hla" to "src/os2_sysexec.o"
Error in file "src/os2_sysexec.hla" at line 117 [errid:77784/hlaparse.bsn]:
Expected ':', encountered '('
(Possible undefined ID '.exists').
Near: << ( >>
HLAPARSE assembly failed with 1 errors
fo.hla"]
thanks. that's a relic from the older hlalib. there are two places in the code where that should change to filesys.exists.
Quote
(even after correcting it still does not compile on linux, since you said that os2_sysexec.hla can be ignored I will but I thought to still tell you of the error)
did you change both of them?
Quote
Oddly linux hla still calls ld even though I specified -vc options:
that is odd.
Quote
aside from src/os2_sysexec this is the hidelib.a listing after compile
looks like everything that needs to be in is in.
Quote
test apps (okay you warned they were out of date in the source but I thought to give them a try)
Error in file "hidelibtest.hla" at line 61 [errid:81732/hlaparse.bsn]:
Error in file "hidelibtest.hla" at line 72 [errid:77784/hlaparse.bsn]:
hide.extract and hide.scanf (I tried replacing hide.extract with scan.extract which looked similar but they must be different enough. Found no replacement for scanf)
that is old stuff! i don't know why i kept those file in there, the latest test program is testLib.hla in the same folder. but i have a lot of stuff commented out and it's not really a benchmark test. it's mostly for me testing out new stuff. one of these days i should write a really in depth testing program.
anyway, the entire hide.scanxx line has been replaced by the scan.xxxx namespace. and the new 'scanf' is the scan.find
Quote
Testlib.hla was a windows app so I didn't try that one.
it's not except for the debug stuff which you can comment out. that includes #include("hide/dbgwin.hhf") as well as everything in the dbg. namespace.
Quote
I tried to keep os2_sysexec but it still had issues. There is no fileio.exists and filesys.exists won't work. Wrong parameter or something I didn't work at that one too hard since it was possible to build with out that file.
Linux version attached if any one is brave to try.
I am going to try kmake and guilib next.
i may just fire up my rusting ubuntu one of these days just to test things out. but it looks like you've overcome most of it already!
Quote
Quote from: Sevag.K on February 02, 2011, 02:26:31 AM
thanks. that's a relic from the older hlalib. there are two places in the code where that should change to filesys.exists.
did you change both of them?
Yes but it still flags it.
Quote
Oddly linux hla still calls ld even though I specified -vc options:
Quote
that is odd.
Just had a thought; maybe hla doesn't let you combine the options ie I need to specify -v -c seperately. I'll have to try that. It is common on linux to be able to do that.
Quote
that is old stuff! i don't know why i kept those file in there, the latest test program is testLib.hla in the same folder. but i have a lot of stuff commented out and it's not really a benchmark test. it's mostly for me testing out new stuff. one of these days i should write a really in depth testing program.
anyway, the entire hide.scanxx line has been replaced by the scan.xxxx namespace. and the new 'scanf' is the scan.find
I'll have to try and see.
Quote
Testlib.hla was a windows app so I didn't try that one.
Quote
it's not except for the debug stuff which you can comment out. that includes #include("hide/dbgwin.hhf") as well as everything in the dbg. namespace.
I avoided cause I assumed that anything that used the debug functions were windows specific. I'll have to look again.
Quote
I tried to keep os2_sysexec but it still had issues. There is no fileio.exists and filesys.exists won't work. Wrong parameter or something I didn't work at that one too hard since it was possible to build with out that file.
Linux version attached if any one is brave to try.
I am going to try kmake and guilib next.
Quote
i may just fire up my rusting ubuntu one of these days just to test things out. but it looks like you've overcome most of it already!
:) Good Luck.
I was trying to build kmake and guilib a few minutes ago and for guilib I think everything is okay except for some reason I can't get hla or ld to link with guilib.a; it can't seem to find it. I even placed it in the same directory with hlalib.a
Last attempt on guilib.hla was this:
Linking via [ld -o "src/guilib" "src/guilib.o" "/media/data/Programming/asm/hlalib/hlalib.a"]
src/guilib.o: In function `_findEnvp_$$_':
(.text+0x36f): undefined reference to `tFrame_create'
Error returned by ld = 256
For kmake I see something here:
Assembling "src/imports.hla" to "src/imports.o"
Error in file "src/kmake.hhf" at line 32 [errid:11027/hlaparse.bsn]:
Undefined base type identifier.
Near: << listNode_t >>
Error in file "src/kmake.hhf" at line 53 [errid:11027/hlaparse.bsn]:
Undefined base type identifier.
Near: << baseNode_t >>
That has popped up before with the hidelib test app code.
get the latest version i just put up at my site. it incorporates the recent changes.
https://sites.google.com/site/highlevelassembly/downloads
the linking issues you're having may be related to the order in which you link the files. link in hidelib.a before guilib.a
i believe ld does sequential symbol search as the libraries are linked in and doesn't want to look ahead for missing symbols.
Quote from: Sevag.K on February 03, 2011, 11:24:56 PM
get the latest version i just put up at my site. it incorporates the recent changes.
https://sites.google.com/site/highlevelassembly/downloads
the linking issues you're having may be related to the order in which you link the files. link in hidelib.a before guilib.a
i believe ld does sequential symbol search as the libraries are linked in and doesn't want to look ahead for missing symbols.
Not sure how to do that. I have tried a few options for ld but nothing seems to set hidelib before guilib.
os2_sysexec.hla still fails because it doesn't recognize filesys.exists as a valid ID.
But it looks like that hidelib will still compile anyway just without that file.
guilibtest.hla (just added test to guilib.hla so as to avoid confusion with lib source code) fails.
ld can't find either lib and when I specify on the command line or the makefile the exact path I get this:
Command:
hla -v src/guilibtest.hla /media/data/Programming/asm/hlalib/hide/hidelib.a /media/data/Programming/asm/hlalib/hide/guilib.a
Output:
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_events.o): In function `false__hla_2442':
(.text+0x16): undefined reference to `MEM2_FILLMEM'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_events.o): In function `str__hla_2436':
(.text+0x90): undefined reference to `_VMT_tClone___hla_'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_events.o): In function `_VMT_tEvent___hla_':
(.text+0x94): undefined reference to `tClone_clone'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_events.o): In function `_VMT_tEvent___hla_':
(.text+0x98): undefined reference to `tClone_isClone'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `forever__hla_2484':
(.text+0x23): undefined reference to `XNextEvent'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `false__hla_2485':
(.text+0x6b): undefined reference to `XKeycodeToKeysym'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `false__hla_2486':
(.text+0x111): undefined reference to `XKeycodeToKeysym'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `exitloop__hla_2483':
(.text+0x557): undefined reference to `XDestroyWindow'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `exitloop__hla_2483':
(.text+0x562): undefined reference to `XCloseDisplay'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `false__hla_2522':
(.text+0x583): undefined reference to `MEM2_FILLMEM'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `tGraphics_eraseBackground':
(.text+0x5b6): undefined reference to `XClearWindow'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `tGraphics_setForegroundColor':
(.text+0x5e5): undefined reference to `XSetForeground'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `tGraphics_setBackgroundColor':
(.text+0x615): undefined reference to `XSetBackground'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `tGraphics_setBackgroundColor':
(.text+0x626): undefined reference to `XSetWindowBackground'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `tGraphics_drawString':
(.text+0x65e): undefined reference to `XDrawString'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `false__hla_2556':
(.text+0x6bc): undefined reference to `XOpenDisplay'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `false__hla_2556':
(.text+0x6d2): undefined reference to `XDefaultRootWindow'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `false__hla_2556':
(.text+0x6f2): undefined reference to `XCreateSimpleWindow'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `false__hla_2556':
(.text+0x710): undefined reference to `XSelectInput'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `false__hla_2556':
(.text+0x722): undefined reference to `XCreateGC'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `false__hla_2556':
(.text+0x736): undefined reference to `XSetForeground'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `false__hla_2556':
(.text+0x747): undefined reference to `XSetBackground'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `false__hla_2556':
(.text+0x758): undefined reference to `XSetWindowBackground'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `false__hla_2556':
(.text+0x76a): undefined reference to `XInternAtom'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `false__hla_2556':
(.text+0x784): undefined reference to `XSetWMProtocols'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `tFrame_show':
(.text+0x7cb): undefined reference to `XMapWindow'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `tFrame_show':
(.text+0x7da): undefined reference to `XClearWindow'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `tFrame_setSize':
(.text+0x82a): undefined reference to `XMoveResizeWindow'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `tFrame_setText':
(.text+0x877): undefined reference to `XStringListToTextProperty'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `tFrame_setText':
(.text+0x899): undefined reference to `XSetWMProperties'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `_VMT_tFrame___hla_':
(.text+0x940): undefined reference to `tClone_clone'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `_VMT_tFrame___hla_':
(.text+0x944): undefined reference to `tClone_isClone'
/media/data/Programming/asm/hlalib/hide/guilib.a(root_objects.o): In function `str__hla_2438':
(.text+0x174): undefined reference to `_VMT_tClone___hla_'
/media/data/Programming/asm/hlalib/hide/guilib.a(root_objects.o): In function `tComponentVMT':
(.text+0x178): undefined reference to `tClone_clone'
/media/data/Programming/asm/hlalib/hide/guilib.a(root_objects.o): In function `tComponentVMT':
(.text+0x17c): undefined reference to `tClone_isClone'
/media/data/Programming/asm/hlalib/hide/guilib.a(root_objects.o): In function `tContainerVMT':
(.text+0x1b0): undefined reference to `tClone_clone'
/media/data/Programming/asm/hlalib/hide/guilib.a(root_objects.o): In function `tContainerVMT':
(.text+0x1b4): undefined reference to `tClone_isClone'
/media/data/Programming/asm/hlalib/hide/guilib.a(root_objects.o): In function `tWindowVMT':
(.text+0x1e8): undefined reference to `tClone_clone'
/media/data/Programming/asm/hlalib/hide/guilib.a(root_objects.o): In function `tWindowVMT':
(.text+0x1ec): undefined reference to `tClone_isClone'
ld's error is this:
Linking via [ld -o "src/guilibtest" "src/guilibtest.o" "/media/data/Programming/asm/hlalib/hide/hidelib.a" "/media/data/Programming/asm/hlalib/hide/guilib.a" "/media/data/Programming/asm/hlalib/hlalib.a"]
Error returned by ld = 256
Looks like it still can't find the libraries.
They are actually located in the above path but I don't get why ld is having an issue.
Quote from: DarkWolf on February 22, 2011, 08:44:13 PM
Not sure how to do that. I have tried a few options for ld but nothing seems to set hidelib before guilib.
linking order matters i think. since guilib calls on hlalib functions, hlalib has to be linked first on the commandline.
so...
Linking via [ld -o "src/guilib" "src/guilib.o" "/media/data/Programming/asm/hlalib/hlalib.a"]
instead of that, use
Linking via [ld -o "src/guilib" "/media/data/Programming/asm/hlalib/hlalib.a" "src/guilib.o" ]
Quote
os2_sysexec.hla still fails because it doesn't recognize filesys.exists as a valid ID.
But it looks like that hidelib will still compile anyway just without that file.
guilibtest.hla (just added test to guilib.hla so as to avoid confusion with lib source code) fails.
ld can't find either lib and when I specify on the command line or the makefile the exact path I get this:
Command:
hla -v src/guilibtest.hla /media/data/Programming/asm/hlalib/hide/hidelib.a /media/data/Programming/asm/hlalib/hide/guilib.a
Output:
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_events.o): In function `false__hla_2442':
(.text+0x16): undefined reference to `MEM2_FILLMEM'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_events.o): In function `str__hla_2436':
(.text+0x90): undefined reference to `_VMT_tClone___hla_'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_events.o): In function `_VMT_tEvent___hla_':
(.text+0x94): undefined reference to `tClone_clone'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_events.o): In function `_VMT_tEvent___hla_':
(.text+0x98): undefined reference to `tClone_isClone'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `forever__hla_2484':
(.text+0x23): undefined reference to `XNextEvent'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `false__hla_2485':
(.text+0x6b): undefined reference to `XKeycodeToKeysym'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `false__hla_2486':
(.text+0x111): undefined reference to `XKeycodeToKeysym'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `exitloop__hla_2483':
(.text+0x557): undefined reference to `XDestroyWindow'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `exitloop__hla_2483':
(.text+0x562): undefined reference to `XCloseDisplay'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `false__hla_2522':
(.text+0x583): undefined reference to `MEM2_FILLMEM'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `tGraphics_eraseBackground':
(.text+0x5b6): undefined reference to `XClearWindow'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `tGraphics_setForegroundColor':
(.text+0x5e5): undefined reference to `XSetForeground'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `tGraphics_setBackgroundColor':
(.text+0x615): undefined reference to `XSetBackground'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `tGraphics_setBackgroundColor':
(.text+0x626): undefined reference to `XSetWindowBackground'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `tGraphics_drawString':
(.text+0x65e): undefined reference to `XDrawString'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `false__hla_2556':
(.text+0x6bc): undefined reference to `XOpenDisplay'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `false__hla_2556':
(.text+0x6d2): undefined reference to `XDefaultRootWindow'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `false__hla_2556':
(.text+0x6f2): undefined reference to `XCreateSimpleWindow'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `false__hla_2556':
(.text+0x710): undefined reference to `XSelectInput'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `false__hla_2556':
(.text+0x722): undefined reference to `XCreateGC'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `false__hla_2556':
(.text+0x736): undefined reference to `XSetForeground'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `false__hla_2556':
(.text+0x747): undefined reference to `XSetBackground'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `false__hla_2556':
(.text+0x758): undefined reference to `XSetWindowBackground'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `false__hla_2556':
(.text+0x76a): undefined reference to `XInternAtom'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `false__hla_2556':
(.text+0x784): undefined reference to `XSetWMProtocols'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `tFrame_show':
(.text+0x7cb): undefined reference to `XMapWindow'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `tFrame_show':
(.text+0x7da): undefined reference to `XClearWindow'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `tFrame_setSize':
(.text+0x82a): undefined reference to `XMoveResizeWindow'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `tFrame_setText':
(.text+0x877): undefined reference to `XStringListToTextProperty'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `tFrame_setText':
(.text+0x899): undefined reference to `XSetWMProperties'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `_VMT_tFrame___hla_':
(.text+0x940): undefined reference to `tClone_clone'
/media/data/Programming/asm/hlalib/hide/guilib.a(guilib_frameControl.o): In function `_VMT_tFrame___hla_':
(.text+0x944): undefined reference to `tClone_isClone'
/media/data/Programming/asm/hlalib/hide/guilib.a(root_objects.o): In function `str__hla_2438':
(.text+0x174): undefined reference to `_VMT_tClone___hla_'
/media/data/Programming/asm/hlalib/hide/guilib.a(root_objects.o): In function `tComponentVMT':
(.text+0x178): undefined reference to `tClone_clone'
/media/data/Programming/asm/hlalib/hide/guilib.a(root_objects.o): In function `tComponentVMT':
(.text+0x17c): undefined reference to `tClone_isClone'
/media/data/Programming/asm/hlalib/hide/guilib.a(root_objects.o): In function `tContainerVMT':
(.text+0x1b0): undefined reference to `tClone_clone'
/media/data/Programming/asm/hlalib/hide/guilib.a(root_objects.o): In function `tContainerVMT':
(.text+0x1b4): undefined reference to `tClone_isClone'
/media/data/Programming/asm/hlalib/hide/guilib.a(root_objects.o): In function `tWindowVMT':
(.text+0x1e8): undefined reference to `tClone_clone'
/media/data/Programming/asm/hlalib/hide/guilib.a(root_objects.o): In function `tWindowVMT':
(.text+0x1ec): undefined reference to `tClone_isClone'
ld's error is this:
Linking via [ld -o "src/guilibtest" "src/guilibtest.o" "/media/data/Programming/asm/hlalib/hide/hidelib.a" "/media/data/Programming/asm/hlalib/hide/guilib.a" "/media/data/Programming/asm/hlalib/hlalib.a"]
Error returned by ld = 256
Looks like it still can't find the libraries.
They are actually located in the above path but I don't get why ld is having an issue.
i'll take a look at this when i get the time. but just as a reminder, you also have to link in the x libraries to your test program. khla used to do this automatically, but as i've said, khla is abandoned and i don't even have the sources anymore. maybe it's online somewhere and you can find the source line with the proper ld command line to use.
Who wrote this crap ?!
First ld will not search the path I give it on the command line for the libraries.
I cannot specify /media/data/Programming/asm/hlalib/hlalib.a (yes I keep my programming stuff that deep)
It will never search there, it will never try.
The -l switch does not specify a path, so I cannot use "-l /media/data/Programming/asm/hlalib/hlalib.a" (actually I use a macro but this is what it expands to)
The -L specifies the path but not a file name. "-L /media/data/Programming/asm/hlalib"
The makefile command:
ld --verbose -o "bin/my_guilibtest" -L "$(hla_lib)" -L "$(hide_lib)" -l "/hlalib.a" -l "hidelib.a" -l "guilib.a" "src/guilibtest.o" >> log/build.log
Here's where it actually looked :
attempt to open /media/data/Programming/asm/hlalib/lib/hlalib.a.so failed
attempt to open /media/data/Programming/asm/hlalib/lib/hlalib.a.a failed
Yes that's right not only does -L appends a /lib to the file path but -l appends both a .a and .so to the file name. No wonder it can't find shit.
I can't find anything in the man page to alter this.