Apologies for this

[Peter West]

To James; if you would like a reply to an offline email, please use an 
accessible email address. The last time I tried to reply, my message bounced.


—
p...@ehealth.id.au
“…you refuse to come to me that you may have life.”

Re: read() on dir

[Peter West]

Thanks, Richard, for the history lesson.

peter
—
p...@ehealth.id.au
“…an hour is coming when all who are in the tombs will hear his voice and come 
out…”

> On 18 Mar 2021, at 2:50 am, Richard L. Hamilton  wrote:
> 
> I think you may be mixing apples and oranges.
> 
> As I recall, the ability to literally use read() began in very early Unix, 
> when only one filesystem type existed (before SVR3 FSS or BSD VFS mechanisms 
> that allowed multiple filesystem implementations). The original type had 
> 16-byte entries, with two bytes of inode number (pretty small number of 
> inodes/files that allows on a filesystem!) and fourteen bytes of file name, 
> null byte padded on the right, but only null byte terminated if less than 
> fourteen bytes. That was easy, and not too demanding on old, small systems. 
> Note that mkdir() was not even a separate system call early on, it was just 
> mknod() with the arguments needed to create an empty directory, followed by 
> link() calls (allowed as root, mkdir command was setuid) to create "." and 
> ".." links. rmdir simply checked that only those two links remained, unlinked 
> them, and then unlinked the once-again empty (logically) directory.
> 
> But it had some disadvantages, like fragmentation. BSD UFS uses a data 
> structure that resembles (but is not identical to) what readdir() returns.
> 
> Both of those (even once VFS came into existence) allowed actual read() calls 
> on a directory for backwards compatibility, ONLY on certain filesystem types 
> (SysV FS variants and UFS, mainly). Since different filesystems could 
> implement directories differently (or even not really implement them at all, 
> just implement the illusion of them in some indexing scheme supplemented with 
> attributes for the directory nodes - what HFS, APFS, ZFS, etc do, more or 
> less), and since sharing filesystems like NFS abstracted the directory 
> structure anyway (hiding the "real" structure on the server), newer 
> filesystems disallow direct read() of directories; it's really not to useful 
> for anything other than maybe a low-level filesystem debugger or repair tool 
> to know how directories are stored.
> 
> Along with FSS or VFS introducing readdir() (or actually getdents() or 
> getdirentries(), on top of which readdir() was a library routine), mkdir() 
> and rmdir() became system calls (no setuid helper needed anymore), read() of 
> directories was as I said mostly disallowed except for compatibility on the 
> oldest filesystem types, and link() or unlink() on directories mostly 
> disallowed even for root (I think). With the backwards compatibility 
> exceptions, that make directories abstract enough to impose no particular 
> limits on how they were implemented, save that they had to handle a minimum 
> file length, and have either per-directory attributes (permission bits, UID, 
> GID, timestamps, etc) or at least have the filesystem fake those when they 
> didn't really exist (as PCFS does).
> 
> That discussion roughly (I probably got some details wrong) covers the 
> history of physically reading a directory. But what vi (vim, really) does is 
> quite different. It simply stat()s a pathname, and if that reveals that the 
> pathname is a directory, it does a readdir(), and stat()s each of the 
> returned entries to discover if it's a file or directory, and then presents a 
> listing upon which one can perform certain actions (scroll through it, hit 
> return to edit/view the file or directory, etc). That is code within vim, and 
> does NOT require or depend on being able to read() a directory. Other 
> programs do similar things; for example, Finder and/or launch services on a 
> Mac can "open" a fairly arbitrary pathname or even some URL types, but 
> certainly does not depend on a single system call or sometimes even a single 
> program to provide the behavior; it's a higher level abstraction, is all.
> 
> Other vi-like programs (original vi and its code base descendants such as the 
> nvi port, elvis, vile, viper, etc) may or may not have a feature similar to 
> the :Explorer or directory "editing" feature in vim.
> 
> It's quite a different question, a philosophical one if you will, whether a 
> text editor should have a minimal file manager capability, as vim does. I 
> don't see why not, if you don't mind a somewhat bigger code base and 
> executable, since it already has :n and :N (or :prev) commands, allowing one 
> to step through a list of files - not like it's all THAT much extra code 
> required.
> 
> 
>> On Mar 17, 2021, at 11:19, Christoph Kukulies > > wrote:
>> 
>> There was some discussion in the FreeBSD mailing list about changing the 
>> behaviour of a directory fd WRT
>> the read() function. A change has been made towards disallowing this from 
>> FreeBSD 12.2 onwards (IIRC) and there was big discussion on this since it
>> „violates“ the cleanness of UNIX, that a file is a file is a file or 
>> „everything is a file“. Many 

Re: read() on dir

[Richard L. Hamilton]

I think you may be mixing apples and oranges.

As I recall, the ability to literally use read() began in very early Unix, when 
only one filesystem type existed (before SVR3 FSS or BSD VFS mechanisms that 
allowed multiple filesystem implementations). The original type had 16-byte 
entries, with two bytes of inode number (pretty small number of inodes/files 
that allows on a filesystem!) and fourteen bytes of file name, null byte padded 
on the right, but only null byte terminated if less than fourteen bytes. That 
was easy, and not too demanding on old, small systems. Note that mkdir() was 
not even a separate system call early on, it was just mknod() with the 
arguments needed to create an empty directory, followed by link() calls 
(allowed as root, mkdir command was setuid) to create "." and ".." links. rmdir 
simply checked that only those two links remained, unlinked them, and then 
unlinked the once-again empty (logically) directory.

But it had some disadvantages, like fragmentation. BSD UFS uses a data 
structure that resembles (but is not identical to) what readdir() returns.

Both of those (even once VFS came into existence) allowed actual read() calls 
on a directory for backwards compatibility, ONLY on certain filesystem types 
(SysV FS variants and UFS, mainly). Since different filesystems could implement 
directories differently (or even not really implement them at all, just 
implement the illusion of them in some indexing scheme supplemented with 
attributes for the directory nodes - what HFS, APFS, ZFS, etc do, more or 
less), and since sharing filesystems like NFS abstracted the directory 
structure anyway (hiding the "real" structure on the server), newer filesystems 
disallow direct read() of directories; it's really not to useful for anything 
other than maybe a low-level filesystem debugger or repair tool to know how 
directories are stored.

Along with FSS or VFS introducing readdir() (or actually getdents() or 
getdirentries(), on top of which readdir() was a library routine), mkdir() and 
rmdir() became system calls (no setuid helper needed anymore), read() of 
directories was as I said mostly disallowed except for compatibility on the 
oldest filesystem types, and link() or unlink() on directories mostly 
disallowed even for root (I think). With the backwards compatibility 
exceptions, that make directories abstract enough to impose no particular 
limits on how they were implemented, save that they had to handle a minimum 
file length, and have either per-directory attributes (permission bits, UID, 
GID, timestamps, etc) or at least have the filesystem fake those when they 
didn't really exist (as PCFS does).

That discussion roughly (I probably got some details wrong) covers the history 
of physically reading a directory. But what vi (vim, really) does is quite 
different. It simply stat()s a pathname, and if that reveals that the pathname 
is a directory, it does a readdir(), and stat()s each of the returned entries 
to discover if it's a file or directory, and then presents a listing upon which 
one can perform certain actions (scroll through it, hit return to edit/view the 
file or directory, etc). That is code within vim, and does NOT require or 
depend on being able to read() a directory. Other programs do similar things; 
for example, Finder and/or launch services on a Mac can "open" a fairly 
arbitrary pathname or even some URL types, but certainly does not depend on a 
single system call or sometimes even a single program to provide the behavior; 
it's a higher level abstraction, is all.

Other vi-like programs (original vi and its code base descendants such as the 
nvi port, elvis, vile, viper, etc) may or may not have a feature similar to the 
:Explorer or directory "editing" feature in vim.

It's quite a different question, a philosophical one if you will, whether a 
text editor should have a minimal file manager capability, as vim does. I don't 
see why not, if you don't mind a somewhat bigger code base and executable, 
since it already has :n and :N (or :prev) commands, allowing one to step 
through a list of files - not like it's all THAT much extra code required.


> On Mar 17, 2021, at 11:19, Christoph Kukulies  wrote:
> 
> There was some discussion in the FreeBSD mailing list about changing the 
> behaviour of a directory fd WRT
> the read() function. A change has been made towards disallowing this from 
> FreeBSD 12.2 onwards (IIRC) and there was big discussion on this since it
> „violates“ the cleanness of UNIX, that a file is a file is a file or 
> „everything is a file“. Many purists were against the disallowing behaviour.
> 
> At that time I cross checked whether this is allowed in macOS and - again 
> IIRC - at that time (Catalina) it was disallowed either to do
> a „vi .“:
> 
> $ vi /tmp
> 
> " 
> " Netrw Directory Listing(netrw v168)
> "   

Re: read() on dir

[Christoph Kukulies]

Argh! I was wrong.

$ cat /tmp
cat: /tmp: Is a directory


Sorry for the noise.


> Am 17.03.2021 um 16:19 schrieb Christoph Kukulies :
> 
> There was some discussion in the FreeBSD mailing list about changing the 
> behaviour of a directory fd WRT
> the read() function. A change has been made towards disallowing this from 
> FreeBSD 12.2 onwards (IIRC) and there was big discussion on this since it
> „violates“ the cleanness of UNIX, that a file is a file is a file or 
> „everything is a file“. Many purists were against the disallowing behaviour.
> 
> At that time I cross checked whether this is allowed in macOS and - again 
> IIRC - at that time (Catalina) it was disallowed either to do
> a „vi .“:
> 
> $ vi /tmp
> 
> " 
> " Netrw Directory Listing(netrw v168)
> "   /tmp
> "   Sorted by  name
> "   Sort sequence: 
> [\/]$,\,\.h$,\.c$,\.cpp$,\~\=\*$,*,\.o$,\.obj$,\.info$,\.swp$,\.bak$,\~$
> "   Quick Help: :help  -:go up dir  D:delete  R:rename  s:sort-by  
> x:special
> " 
> ==
> ../   
>  
> ./
> .vbox-kuku-ipc/
> com.apple.launchd.AUnEPqi6tC/
> com.apple.launchd.atGF3BeR4X/
> com.apple.launchd.lOdpt02m8q/
> powerlog/
> FirstBootAfterUpdate
> FirstBootCleanupHandled
> OSL_PIPE_501_SingleOfficeIPC_57c1e9acbaf815f47e314f3cbee8d6=
> fseventsd-uuid
> 
> Now I’m surprised that this is possible (again?) under BigSur. I may be 
> totally wrong on this. I don’t have the
> opportunity to cross check that against Catalina. Could someone confirm or 
> proove the opposite?
> 
> —
> Christoph 
> a UNIX dinosaur
> 
> 
> 
> 
> 



smime.p7s
Description: S/MIME cryptographic signature

read() on dir

[Christoph Kukulies]

There was some discussion in the FreeBSD mailing list about changing the 
behaviour of a directory fd WRT
the read() function. A change has been made towards disallowing this from 
FreeBSD 12.2 onwards (IIRC) and there was big discussion on this since it
„violates“ the cleanness of UNIX, that a file is a file is a file or 
„everything is a file“. Many purists were against the disallowing behaviour.

At that time I cross checked whether this is allowed in macOS and - again IIRC 
- at that time (Catalina) it was disallowed either to do
a „vi .“:

$ vi /tmp

" 
" Netrw Directory Listing(netrw v168)
"   /tmp
"   Sorted by  name
"   Sort sequence: 
[\/]$,\,\.h$,\.c$,\.cpp$,\~\=\*$,*,\.o$,\.obj$,\.info$,\.swp$,\.bak$,\~$
"   Quick Help: :help  -:go up dir  D:delete  R:rename  s:sort-by  x:special
" ==
../ 
   
./
.vbox-kuku-ipc/
com.apple.launchd.AUnEPqi6tC/
com.apple.launchd.atGF3BeR4X/
com.apple.launchd.lOdpt02m8q/
powerlog/
FirstBootAfterUpdate
FirstBootCleanupHandled
OSL_PIPE_501_SingleOfficeIPC_57c1e9acbaf815f47e314f3cbee8d6=
fseventsd-uuid

Now I’m surprised that this is possible (again?) under BigSur. I may be totally 
wrong on this. I don’t have the
opportunity to cross check that against Catalina. Could someone confirm or 
proove the opposite?

—
Christoph 
a UNIX dinosaur







smime.p7s
Description: S/MIME cryptographic signature

Re: "port install meld" does not yield working executable

[Ryan Schmidt]

> On Mar 17, 2021, at 07:47, joerg van den hoff wrote:
> 
> 
> 
> On 17.03.21 13:16, Ryan Schmidt wrote:
>> On Mar 17, 2021, at 07:04, joerg van den hoff wrote:
>>> and sadly even `sudo port -ns upgrade --force meld)' does not solve the 
>>> problem...
>>> 
>>> too bad. but I appreciate your help. at least I now understand where 
>>> approximately the problem is located ...
>> According to
>> https://developer.gnome.org/programming-guidelines/stable/introspection.html.en#using-introspection
>> a build of software using gobject-introspection "should result in a .gir and 
>> .typelib file being generated for the project. The .gir file is human 
>> readable, and can be inspected manually to see if the API has been 
>> introspected correctly". I infer that the typelib, therefore, is the same 
>> data but in a machine-readable format. That explains my confusion earlier 
>> about what was meant by the message "referenced by the typelib". It also 
>> explains why editing the installed gir file does nothing: you would need to 
>> make the same change in the binary typelib file before it takes effect, and 
>> depending on how the file is structured that may not be feasible. The real 
>> solution of course is to get gobject-introspection to generate these files 
>> correctly in the first place. Did you try recompiling 
> 
> understood.
> 
> gtksourceview4 (sudo port -ns upgrade --force gtksourceview4) to see if that 
> would happen then? If so, that suggests we just need to revbump 
> gtksourceview4 and other affected ports. If not, then it suggests we need to 
> fix gobject-introspection.
> 
> 
> I uninstalled/reinstalled that port before and now retried with the above 
> command: still no luck. problem stubbornly refuses to go away...
> 


I can at least confirm for you that the same thing happens to me if I build 
gtksourceview4 now, so you're not alone.

The gtksourceview4 I installed on 2021-02-12 did not have this problem. My 
gobject-introspection port was installed before that, on 2021-01-20, so that's 
not the reason why the gir files are being generated differently now, but I 
don't know what is.

Dave, can you take a look at this thread? It's about your ports.

Re: "port install meld" does not yield working executable

[joerg van den hoff]

On 17.03.21 13:16, Ryan Schmidt wrote:

On Mar 17, 2021, at 07:04, joerg van den hoff wrote:


and sadly even `sudo port -ns upgrade --force meld)' does not solve the 
problem...

too bad. but I appreciate your help. at least I now understand where 
approximately the problem is located ...



According to

https://developer.gnome.org/programming-guidelines/stable/introspection.html.en#using-introspection

a build of software using gobject-introspection "should result in a .gir and .typelib file being generated for the project. The .gir file is human readable, and can be inspected manually to see if the API has been introspected correctly". I infer that the typelib, therefore, is the same data but in a machine-readable format. That explains my confusion earlier about what was meant by the message "referenced by the typelib". It also explains why editing the installed gir file does nothing: you would need to make the same change in the binary typelib file before it takes effect, and depending on how the file is structured that may not be feasible. The real solution of course is to get gobject-introspection to generate these files correctly in the first place. Did you try recompiling 


understood.

gtksourceview4 (sudo port -ns upgrade --force gtksourceview4) to see if that would happen then? If 
so, that suggests we just need to revbump gtksourceview4 and other affected ports. If not, then it 
suggests we need to fix gobject-introspection.



I uninstalled/reinstalled that port before and now retried with the above command: still no luck. 
problem stubbornly refuses to go away...

Re: "port install meld" does not yield working executable

[Ryan Schmidt]

On Mar 17, 2021, at 07:04, joerg van den hoff wrote:

> and sadly even `sudo port -ns upgrade --force meld)' does not solve the 
> problem...
> 
> too bad. but I appreciate your help. at least I now understand where 
> approximately the problem is located ...


According to

https://developer.gnome.org/programming-guidelines/stable/introspection.html.en#using-introspection

a build of software using gobject-introspection "should result in a .gir and 
.typelib file being generated for the project. The .gir file is human readable, 
and can be inspected manually to see if the API has been introspected 
correctly". I infer that the typelib, therefore, is the same data but in a 
machine-readable format. That explains my confusion earlier about what was 
meant by the message "referenced by the typelib". It also explains why editing 
the installed gir file does nothing: you would need to make the same change in 
the binary typelib file before it takes effect, and depending on how the file 
is structured that may not be feasible. The real solution of course is to get 
gobject-introspection to generate these files correctly in the first place. Did 
you try recompiling gtksourceview4 (sudo port -ns upgrade --force 
gtksourceview4) to see if that would happen then? If so, that suggests we just 
need to revbump gtksourceview4 and other affected ports. If not, then it 
suggests we need to fix gobject-introspection.

Re: "port install meld" does not yield working executable

[joerg van den hoff]

On 17.03.21 12:39, Ryan Schmidt wrote:
> On Mar 17, 2021, at 06:36, joerg van den hoff wrote:
>> On 17.03.21 11:07, Ryan Schmidt wrote:
>>> I think there is something wrong with your /opt/local/share/gir-1.0/GtkSource-4.gir. 
Specifically in mine, there is the line:

>>> shared-library="/opt/local/lib/libgtksourceview-4.0.dylib"
>>> and I think in yours the line is different. And I think it's this bug:
>>
>> and I think you are very right :). indeed, that line in my case reads 
(surprise!)  
>>
>> shared-library="./gtksourceview/libgtksourceview-4.0.dylib"
>>
>>> https://trac.macports.org/ticket/61792
>>> and this bug:
>>> https://trac.macports.org/ticket/62391
>>> I think gobject-introspection is just broken for the moment. (Or it is fixed but we forgot to 
revbump all the affected ports to rebuild them.)
>>> I guess you could manually edit affected .gir files to fix the shared-library paths to be the 
correct absolute ones.

>>
>> unfortunately, that does not help. I still get the " Failed to load shared library 
'./gtksourceview/libgtksourceview-4.0.dylib' referenced by the typelib: 
dlopen(./gtksourceview/libgtksourceview-4.0.dylib, 9): image not found" error --  despite having 
fixed the/opt/local/share/gir-1.0/GtkSource-4.gir to provide

>>
>> shared-library="/opt/local/lib/libgtksourceview-4.0.dylib
>>
>> and grepping through the other gir-files in that location seems to indicate that this is the 
only reference to that dylib file :|.

>>
>> so still no luck...
>>
>> I don't know about this stuff (gobject-introspection): is it required to reboot or restart some 
process to make changes to the gir file effective? right now it seems `meld' gets that relative path 
all the same or from somewhere else

>
> I don't really know either. But if changing the path in the gir file didn't fix the problem, then 
maybe it only looks at that at build time, in which case maybe you need to rebuild meld (sudo port 
-ns upgrade --force meld) and/or other ports in the dependency chain that use gir-based libraries. 
Before you do a lot of rebuilding, you might want to check if any other gir files in that directory 
have similarly-wrong shared-library lines that should be fixed first.

grep 'shared-library.*\.\/' *.gir

yielded only that single file/line containing a path relative to `./' (prior to 
fixing it).

and sadly even `sudo port -ns upgrade --force meld)' does not solve the 
problem...

too bad. but I appreciate your help. at least I now understand where approximately the problem is 
located ...

Re: "port install meld" does not yield working executable

[Ryan Schmidt]

On Mar 17, 2021, at 06:36, joerg van den hoff wrote:
> On 17.03.21 11:07, Ryan Schmidt wrote:
>> I think there is something wrong with your 
>> /opt/local/share/gir-1.0/GtkSource-4.gir. Specifically in mine, there is the 
>> line:
>> shared-library="/opt/local/lib/libgtksourceview-4.0.dylib"
>> and I think in yours the line is different. And I think it's this bug:
> 
> and I think you are very right :). indeed, that line in my case reads 
> (surprise!) 
> 
> shared-library="./gtksourceview/libgtksourceview-4.0.dylib"
> 
>> https://trac.macports.org/ticket/61792
>> and this bug:
>> https://trac.macports.org/ticket/62391
>> I think gobject-introspection is just broken for the moment. (Or it is fixed 
>> but we forgot to revbump all the affected ports to rebuild them.)
>> I guess you could manually edit affected .gir files to fix the 
>> shared-library paths to be the correct absolute ones.
> 
> unfortunately, that does not help. I still get the " Failed to load shared 
> library './gtksourceview/libgtksourceview-4.0.dylib' referenced by the 
> typelib: dlopen(./gtksourceview/libgtksourceview-4.0.dylib, 9): image not 
> found" error --  despite having fixed 
> the/opt/local/share/gir-1.0/GtkSource-4.gir to provide
> 
> shared-library="/opt/local/lib/libgtksourceview-4.0.dylib
> 
> and grepping through the other gir-files in that location seems to indicate 
> that this is the only reference to that dylib file :|.
> 
> so still no luck...
> 
> I don't know about this stuff (gobject-introspection): is it required to 
> reboot or restart some process to make changes to the gir file effective? 
> right now it seems `meld' gets that relative path all the same or from 
> somewhere else

I don't really know either. But if changing the path in the gir file didn't fix 
the problem, then maybe it only looks at that at build time, in which case 
maybe you need to rebuild meld (sudo port -ns upgrade --force meld) and/or 
other ports in the dependency chain that use gir-based libraries. Before you do 
a lot of rebuilding, you might want to check if any other gir files in that 
directory have similarly-wrong shared-library lines that should be fixed first.

Re: "port install meld" does not yield working executable

[joerg van den hoff]

On 17.03.21 11:07, Ryan Schmidt wrote:



On Mar 17, 2021, at 04:07, joerg van den hoff wrote:

On 17.03.21 05:07, Ryan Schmidt wrote:

On Mar 16, 2021, at 13:47, joerg van den hoff wrote:

"** (meld:70489): WARNING **: 19:46:07.080: Failed to load shared library 
'./gtksourceview/libgtksourceview-4.0.dylib' referenced by the typelib: 
dlopen(./gtksourceview/libgtksourceview-4.0.dylib, 9): image not found
Meld requires GtkSourceView 4.0 or higher.
"

Hmm.
That's a relative path, but I don't know what it's meant to be relative to.


yes, I noted this (and suspected that some (environment?) variable might not be 
set correctly somewhere so that $PWD is used as fallback in its place when 
constructing that path).


On my system, the gtksourceview4 port installs the file 
/opt/local/lib/libgtksourceview-4.0.dylib. Do you have that file?


yes I do:

-rwxr-xr-x  1 root  admin  803912 Mar  9 22:42 
/opt/local/lib/libgtksourceview-4.0.dylib


Hmm again.

meld works fine for me on macOS High Sierra. What macOS and Xcode version are 
you using?


10.15.7 and 12.4



meld is a python script. I added some debugging to mine: right before this line:

 if version < (self.major_version, self.minor_version):

I added this line:

 print("version of %s is %s" % (mod.__name__, version))

Then when I started meld it says:

version of sys is sys.version_info(major=3, minor=8, micro=8, 
releaselevel='final', serial=0)
version of gi.repository.Gtk is (3, 24)
version of gi.repository.GLib is (2, 58)
version of gi.repository.GtkSource is (4, 0)
version of gi is (3, 38, 0)
version of cairo is (1, 20, 0)


if I do the same I get this output:

version of sys is sys.version_info(major=3, minor=8, micro=8, 
releaselevel='final', serial=0)
version of gi.repository.Gtk is (3, 24)
version of gi.repository.GLib is (2, 58)

followed by the " Failed to load shared library 
'./gtksourceview/libgtksourceview-4.0.dylib'" error.



The "gi" in gi.repository.GtkSource alerts me to the fact that this is created 
by gobject-introspection and is the file /opt/local/share/gir-1.0/GtkSource-4.gir. I 
think there is something wrong with your /opt/local/share/gir-1.0/GtkSource-4.gir. 
Specifically in mine, there is the line:

shared-library="/opt/local/lib/libgtksourceview-4.0.dylib"

and I think in yours the line is different. And I think it's this bug:


and I think you are very right :). indeed, that line in my case reads 
(surprise!)   

shared-library="./gtksourceview/libgtksourceview-4.0.dylib"



https://trac.macports.org/ticket/61792

and this bug:

https://trac.macports.org/ticket/62391

I think gobject-introspection is just broken for the moment. (Or it is fixed 
but we forgot to revbump all the affected ports to rebuild them.)

I guess you could manually edit affected .gir files to fix the shared-library 
paths to be the correct absolute ones.


unfortunately, that does not help. I still get the " Failed to load shared library 
'./gtksourceview/libgtksourceview-4.0.dylib' referenced by the typelib: 
dlopen(./gtksourceview/libgtksourceview-4.0.dylib, 9): image not found" error --  despite having 
fixed the/opt/local/share/gir-1.0/GtkSource-4.gir to provide


shared-library="/opt/local/lib/libgtksourceview-4.0.dylib

and grepping through the other gir-files in that location seems to indicate that this is the only 
reference to that dylib file :|.


so still no luck...

I don't know about this stuff (gobject-introspection): is it required to reboot or restart some 
process to make changes to the gir file effective? right now it seems `meld' gets that relative path 
all the same or from somewhere else

Re: "port install meld" does not yield working executable

[Ryan Schmidt]

On Mar 17, 2021, at 04:07, joerg van den hoff wrote:
> On 17.03.21 05:07, Ryan Schmidt wrote:
>> On Mar 16, 2021, at 13:47, joerg van den hoff wrote:
>>> "** (meld:70489): WARNING **: 19:46:07.080: Failed to load shared library 
>>> './gtksourceview/libgtksourceview-4.0.dylib' referenced by the typelib: 
>>> dlopen(./gtksourceview/libgtksourceview-4.0.dylib, 9): image not found
>>> Meld requires GtkSourceView 4.0 or higher.
>>> "
>> Hmm.
>> That's a relative path, but I don't know what it's meant to be relative to.
> 
> yes, I noted this (and suspected that some (environment?) variable might not 
> be set correctly somewhere so that $PWD is used as fallback in its place when 
> constructing that path).
> 
>> On my system, the gtksourceview4 port installs the file 
>> /opt/local/lib/libgtksourceview-4.0.dylib. Do you have that file?
> 
> yes I do:
> 
> -rwxr-xr-x  1 root  admin  803912 Mar  9 22:42 
> /opt/local/lib/libgtksourceview-4.0.dylib

Hmm again.

meld works fine for me on macOS High Sierra. What macOS and Xcode version are 
you using?

meld is a python script. I added some debugging to mine: right before this line:

if version < (self.major_version, self.minor_version):

I added this line:

print("version of %s is %s" % (mod.__name__, version))

Then when I started meld it says:

version of sys is sys.version_info(major=3, minor=8, micro=8, 
releaselevel='final', serial=0)
version of gi.repository.Gtk is (3, 24)
version of gi.repository.GLib is (2, 58)
version of gi.repository.GtkSource is (4, 0)
version of gi is (3, 38, 0)
version of cairo is (1, 20, 0)

The "gi" in gi.repository.GtkSource alerts me to the fact that this is created 
by gobject-introspection and is the file 
/opt/local/share/gir-1.0/GtkSource-4.gir. I think there is something wrong with 
your /opt/local/share/gir-1.0/GtkSource-4.gir. Specifically in mine, there is 
the line:

shared-library="/opt/local/lib/libgtksourceview-4.0.dylib"

and I think in yours the line is different. And I think it's this bug:

https://trac.macports.org/ticket/61792

and this bug:

https://trac.macports.org/ticket/62391

I think gobject-introspection is just broken for the moment. (Or it is fixed 
but we forgot to revbump all the affected ports to rebuild them.)

I guess you could manually edit affected .gir files to fix the shared-library 
paths to be the correct absolute ones.

Re: "port install meld" does not yield working executable

[joerg van den hoff]

On 17.03.21 05:07, Ryan Schmidt wrote:

On Mar 16, 2021, at 13:47, joerg van den hoff wrote:


"** (meld:70489): WARNING **: 19:46:07.080: Failed to load shared library 
'./gtksourceview/libgtksourceview-4.0.dylib' referenced by the typelib: 
dlopen(./gtksourceview/libgtksourceview-4.0.dylib, 9): image not found
Meld requires GtkSourceView 4.0 or higher.
"


Hmm.

That's a relative path, but I don't know what it's meant to be relative to.


yes, I noted this (and suspected that some (environment?) variable might not be set correctly 
somewhere so that $PWD is used as fallback in its place when constructing that path).




On my system, the gtksourceview4 port installs the file 
/opt/local/lib/libgtksourceview-4.0.dylib. Do you have that file?



yes I do:

-rwxr-xr-x  1 root  admin  803912 Mar  9 22:42 
/opt/local/lib/libgtksourceview-4.0.dylib