Re: [Iup-users] Problem linking with scintilla

[Anonymous]

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-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users_______________________________________________
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users