Re: [Iup-users] Problem linking with scintilla
Brought to you by:
scuri
From: Anonymous <ano...@gm...> - 2023-07-17 13:21:14
|
Bom dia! This is an interesting program you've written Sur-Behoffski. I never knew that such a problem existed on Linux until I moved over to Linux six months ago. That means the issue you are working on solving is for Linux only, so before I say any more, let me tell you about my experience with Windows... On Windows I never bothered with installing Lua, IUP, IM, or CD. I just copied all the dlls for those programs into the same folder as the compiler I was using, so the compiler could find them for linking purposes. This would work because on Windows, the first directory it searches for dlls is in the current working directory. So no install needed for that. Then for the actual compiled programs themselves, I copied only the dlls referenced by the program into the same folder as the finished program. That made all my Windows programs portable, which means I can put my program folders on a USB stick, and run my program from there on any system with Windows installed, whether or not the Windows system had IUP installed or not. Now let me tell you about my experience with Linux... It seems I should be able to do something similar on Linux, but being new to Linux, I have no idea how to do that in Linux. All I do know is that Linux doesn't check the current directory for any *.so files when linking files or running programs. Linux _*able*_ do that but it is not easy because it is not at all well documented, and I wanted to stay current with any Linux security principles anyways, so I decided to use *.a files(in Windows they would be *.lib files), which should be easier to do. Except I was wrong. Antonio created a new problem when he said I had to "statically" include various GTK files in my program at compile time to get that to work. First off, there is a problem with terminology. "Statically linked" is supposed to mean I include *.a files, but there are no *.a files listed for GTK, there are only *.so files. That means I can only "dynamically" include those various GTK files which means I can't make any of my programs portable anymore. Secondly, those *.so files have limited scope, meaning they are not directly visible to any program, they only seem to work transparently in the background like driver files do. So I can't compile programs that require those specific *.so files unless I copy them into my current working directory. That doesn't sound professional, it sounds like a hack, so I'm not liking that idea already, but if I have no choice, it's what I must do, but is that what I must do? That is where I currently am at in the process. If I cannot create portable programs with IUP then I will have to consider maybe using iglicua and give up the idea of ever having a portable program, or I will have to use other frameworks like dlangUI or GNUstep (if I can make them portable). The problem is I am too attached to IUP. IUP has many ready-made dialogs and integration with other third party programs (like Scintilla), that no other GUI framework has. What should I do? Signed, Andrew On 7/17/23 03:17, sur-behoffski wrote: > On 7/16/23 06:22, Anonymous wrote: >> Note, the documentation says to use -lpangox-2.0, but their is no libpangox-2.0.so file that exists in the GTK2 or GTK3 directory. Was it supposed to say -lpangoxft-1.0 or -lpangomm-1.4.so or -lpangocairo-1.0.so.0? >> >> On 7/15/23 13:06, Anonymous wrote: >>> My problem is why won't GTK show up in my path, even though the system works with GTK apps? Is that normal? I could copy all the files needed to a directory for static linking ashttps://www.tecgraf.puc-rio.br/iup/ says to do, [...] > G'day, > > I've found and fixed this problem as part of my work on "lglicua": > > https://sourceforge.net/projects/lglicua/files/ > > The problem is that the Tecgraf build infrastructure, especially > "tecmake.mak", but also "iup/srcweb/config.mak", use a test to decide > whether to use GTK2 (older) or GTK3 (newer). Unfortunately, v4.21: > > https://sourceforge.net/p/iup/iup/HEAD/tree/trunk/iup/tecmake.mak > > has code blocks that top out at GNU/Linux Kernel 5, and newer distributions, > notably MX 21.3 and Ubuntu 23.04, use Kernel 6. This overflow of the > kernel numbering results in an incorrect GTK2 selection instead of GTK3, > and compilation and linking mayhem ensues, especially for CD and IUP. > > My Tecgraf Assistant fixes this problem by overriding (stomps on) the > Tecgraf tecmake.mak each time a build is requested. (Note that all of > IM, CD, FTGL, PDFlib7 and IUP all have identical, v4.21 tecmake.mak.) > I released a fixed version (4.30) with the 0.1-alpha8 release, and a > minor cleanup of code formatting (4.31) in 0.1-beta1. > > An example of some problem Makefile code, followed by improved code, is: > > -------- 4.21 (lines 298-317) starts here -------- > > ifdef GTK_DEFAULT > ifndef USE_GTK2 > ifneq ($(findstring Linux5, $(TEC_UNAME)), ) > USE_GTK3 = Yes > endif > ifneq ($(findstring Linux4, $(TEC_UNAME)), ) > USE_GTK3 = Yes > endif > ifneq ($(findstring Linux31, $(TEC_UNAME)), ) > USE_GTK3 = Yes > endif > ifneq ($(findstring cygw, $(TEC_UNAME)), ) > USE_GTK3 = Yes > endif > #Homebrew > #ifneq ($(findstring MacOS10, $(TEC_UNAME)), ) > # USE_GTK3 = Yes > #endif > endif > endif > > -------- 4.21 (lines 298-317) ends here -------- > > -------- 4.31 (lines 261-279) starts here -------- > > # Refine GTK default request: Newer GNU/Linux systems get GTK3, > # unless GTK2 is specifically defined. > ifdef GTK_DEFAULT > ifndef USE_GTK2 > ifeq (Linux, $(TEC_SYSNAME)) > ifneq ($(filter 4 5 6 7 8 9, $(TEC_SYSVERSION)), ) > USE_GTK3 = Yes > else ifneq ($(findstring Linux31, $(TEC_UNAME)), ) > USE_GTK3 = Yes > endif > else ifneq ($(findstring cygw, $(TEC_UNAME)), ) > USE_GTK3 = Yes > endif > #Homebrew > #ifneq ($(findstring MacOS10, $(TEC_UNAME)), ) > # USE_GTK3 = Yes > #endif > endif > endif > > -------- 4.31 (lines 261-279) ends here -------- > > I have tested tecmake.mak 4.31 on the following distributions, using > an array of virtual machines: > > Linux Mint: 21, 21.1 > MX: 21_ahs_x64, 21.1_ahs_x64 [Kernels 5.x.y] , 21.3_ahs_x64 [Kernel 6.0.y]; > CentOS7: > Rocky: 9, 9.1, 9.2; and > Ubuntu: 20.04.3, 22.10 [Kernels 5.x.y], 23.04 [Kernel 6.2.y]. > > -------- > > > I've fed patches for the fixes/changes to tecmake.mak, and he has not > acted on my input. I sent the 4.21 -> 4.30 patches via private email, > and the 4.30 -> 4.31 (smaller set) on the mailing list. > > I note that Scuri has consistently been helpful, but has very limited > time to devote to the IM/CD/IUP toolkits. It's now coming up to three > years since the last major release, and IUP, the most active project, > has had roughly 50 Subversion changes: Some are fixes, some are new > features. This is why my "lglicua" Assistant works from the > SourceForge repository, rather than use the pre-packaged releases. > > Is there some way that we can enable a new release of the toolkits? > Can someone work under Scuri's supervision, if he's unable to devote > time himself, due to other commitments? Can the full packaging > scripts, including test rigs, be documented and released? > > Hopes that the tecmake.mak update fixes build problems, and also > hope that we can make progress on procuring a new release. > > cheers, > > sur-behoffski (Brenton Hoff) > programmer, Grouse Software > > > _______________________________________________ > Iup-users mailing list > Iup...@li... > https://lists.sourceforge.net/lists/listinfo/iup-users |