Search
13:35:30
loke
Inline: That's probably because you have too old versions of freetype/harfbuzz
13:36:20
loke
Inline: If you could #+whatever around the symbols from harfbuzz that fails, I'd be appreciatelive
13:37:43
Inline
yah, but i already installed harfbuzz-1.7.6
13:37:56
loke
I also only have new versions available :-)
13:47:48
Inline
yah but loke newer versions maybe not considered stable, if they are not to be found on the stable packages list.....
13:48:26
loke
I've been trying it on Arch, Fedora-28 and Ubuntu. I don't have any missing symbols on any of them
13:48:46
Inline
i tried it on both mint and trisquel
13:48:57
Inline
and each time i get problems with the groveler
13:49:07
loke
Ubuntu comes with harfbuzz 1.7.2
13:49:25
Inline
so the problem is elsewhere ?
13:49:27
loke
You need to install the devel libraries for harfbuzz freetype and fontconfig
13:50:52
loke
I just pushed a fix that makes DREI work properly with font replacement
13:51:00
loke
Inline: WHat erorr are you gettinbg?
13:51:21
Inline
some scripts are defined for which the library lacks the symbols or so....
13:51:28
Inline
it errors on the groveler stage
13:51:50
Inline
i edited your groveler.lisp to get rid of some of the scripts
13:52:00
loke
You can comment out the entire section that defines symbols for the different languages
13:52:08
Inline
and then the compilation proceeds but i get thrown into the debugger anyway
13:52:20
loke
Inline: Can you give me a stack trace?
13:52:47
Inline
wait a little, it seems to proceed normally now
13:53:19
Inline
it's too late for a stacktrace, as i purged some of the symbols and retried starting my repl, i even got into ldb
13:54:02
Inline
so i repulled the groveler.lisp
13:54:08
Inline
and it seems to proceed ok now
13:54:33
Inline
as i also put the "/usr/local/lib/" onto the asdf registry
13:54:55
Inline
maybe it gives preference to the newer harfbuzz libs that way
13:55:27
Inline
anyway i'll see if it really gets ok to the end of starting my repl now
13:56:52
Inline
cause my installation of harfbuzz put the libs there and before it was maybe linking against the old libs
13:57:04
Inline
i think that might have been it
13:57:25
Inline
i also changed my ld.so.conf
13:57:52
Inline
from include ld.so.conf.d/*.conf to include ld.so.conf.d/libc.conf include ld.so.conf.d/*.conf
13:58:13
Inline
giving preference to /usr/local/lib first, not sure if that was the case anyway
13:58:27
Inline
hmm, i get thrown into debugger now again
13:58:47
Inline
error is: The alien function "hb_ft_font_set_load_flags" is undefined.
13:59:38
Inline
before starting my repl, but after having compiled harfbuzz etc all allready
14:01:56
loke
Inline: Did you ever get a version of this stuff working?
14:02:29
loke
Anyway, here's the current state: https://photos.app.goo.gl/b9WFHeV6u9NcFwxq9
14:02:42
Inline
yes, once where i removed that reference to that function before compiling and installing harfbuzz from sources
14:03:00
Inline
i'm cloning harfbuzz via git now
14:03:06
Inline
i'll try the git version
14:03:15
Inline
maybe it's better suited
14:03:33
loke
Inline: Can you check with "ldd" if your harfbuzz actually has that function?
14:03:40
loke
(it's supposed to, it's quite fundamental)
14:04:14
loke
also use "pldd" to check your sbcl process which harfbuzz you're using./
14:08:34
Inline
that symbol does not exist
14:08:50
Inline
i only have hb_ft_font_set_funcs
14:09:17
loke
Inline: Have you confirmed what harfbuzz you're using?
14:09:24
Inline
and all is rather to be found in the .a file, the .so 's seem to lack any symbols
14:09:48
loke
Inline: Ah, no. That's a linuxism
14:10:49
Inline
i just restarted it, i'll have to wait, and then check with pldd
14:12:02
loke
If pld fails, just use cat /proc/PID/maos | grep harfbuzz
14:12:47
loke
And for nm, use "nm -D libname.so"
14:13:11
loke
-D gives you the dynamic symbols
14:17:51
Inline
yah, it's using the old system provided libs
14:18:14
Inline
i already installed a newer version of harfbuzz in /usr/local/lib
14:18:41
Inline
pldd failed, as sbcl got into a sleeping phase on throwing me into the debugger
14:18:52
Inline
as cat /proc/pid/status reveals
14:19:07
Inline
but the maps tell me it's using the old version
14:19:17
Inline
so how can i override that ?
14:20:39
Inline
and the symbol is findable in the newer version
14:20:42
loke
Inline: the search order is specified in ld.so.conf
14:21:07
Inline
yes but ld.so.conf already has as first entry libc.so which just has 1 entry
14:21:22
loke
Inline: Then I don't know.
14:21:31
loke
I haven't seen this issue with any other linux I tried with.
14:21:50
Inline
wait a little i'll just purge all of .cache/common-lisp
14:22:38
loke
It's possible it always picks up /usr/lib first.
14:22:49
loke
How old version of harfbuzz does your system come with, really?
14:25:10
Inline
no, as i saw it compile the libs, before getting to the grovel stage, it consults pkgconfig
14:25:35
Inline
and guess which one will pkgconfig tell ?
14:25:52
loke
Inline: WHich version of harfbuzz does you system come with?
14:27:21
Inline
hmmm, nvm, pkgconfig reports ok via --cflags and --libs
14:27:29
Inline
-L/usr/local/lib -lharfbuzz
14:27:35
loke
Inline: CFFI doesn't use pkgconfig, I don't think
14:27:37
Inline
-I/usr/local/include/harfbuzz -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include
14:27:47
loke
Now... for the 100'th time: What version of harfbuzz does your system come with?
14:28:36
Inline
Version: 1.0.1-1ubuntu0.1
14:28:45
loke
Oh wow... That's positively ancient
14:28:58
loke
Are you sure you shouldn't just upgrade your distro?
14:29:20
Inline
there's nothing left to upgrade
14:29:38
Inline
i even added the backports repo now
14:29:44
Inline
and still there's nothing to be done
14:30:01
Inline
but the problem was the same on mint
14:30:11
Inline
i suppose i'd have to change to the testing versions or so
14:30:44
Inline
and everytime i do such things, i shoot myself in the knee
14:31:51
loke
Yes. Just checked here: http://archive.trisquel.info/trisquel/dists/flidas/main/source/
14:32:02
loke
The latest release version really does come with an outdated harfbuzz
14:32:09
loke
What kind of crap distro is that?
14:32:56
Inline
ya i think i should change back to slack or so.....
14:34:00
Inline
with all the occasional corruption....
14:34:14
loke
I'm looking at the trsiquel web site. I see no explanation as to why it exists. :-)
14:34:40
loke
Maybe the FAQ has something to say
14:35:42
loke
Oh... it's a "freedom or death" distro
14:35:57
loke
If that's what you want, you're probably better off with debian
14:36:14
Inline
i even saw it use the correct pkg-config --cflags
14:36:24
Inline
but it threw me into debugger again
14:36:26
loke
Anyway, at least we now know what the problem is.
14:36:38
loke
Inline: I don't think CFFI uses pkg-config to find the libs
14:36:55
Inline
but somewhere on loading it i saw pkg-config mentioned
14:39:55
Inline
grovel.lisp uses pkg-config
14:40:25
loke
Ah. So it uses the new version when compiling the grovel files, but probably loads the old library when you run the code.
14:40:31
loke
That's why compiling works.
14:41:21
loke
try setting CFFI:*FOREIGN-LIBRARY-DIRECTORIES* before loading
14:41:38
loke
set it to (list #p"/usr/local/lib/")
14:54:06
Inline
it uses (include "hb-ft") in grovel.lisp
14:54:16
Inline
and maybe that one refers to the /usr/include path
14:54:25
Inline
not sure what's wrong really
14:54:39
Inline
and both attempts failed
14:55:32
Inline
i'll put it just before i (ql:quickload :maxima-client)
14:55:41
Inline
and cleanse .cache first
14:57:31
loke
Inline: the include stuff is used by the griveller. Not when running.
14:59:07
Inline
are globals not visible from closures ?
14:59:21
Inline
cause i start it from within a closure
14:59:33
Inline
but i suppose they are not visible from within threads right ?
15:23:47
Inline
ok putting that stuff globally doesn't work
15:27:18
Inline
i put it in harbuzz.lisp
15:27:42
loke
By it, I believe you meant the load-path?
15:28:53
Inline
it defines the foreign-library harfbuzz
15:29:02
Inline
(cffi:define-foreign-library libharfbuzz
15:29:02
Inline
(:darwin "libharfbuzz.dylib")
15:29:02
Inline
(:unix "libharfbuzz.so"))
15:29:14
Inline
(setq cffi:*foreign-library-directories* (list #p"/usr/local/lib/"))
15:29:14
Inline
(cffi:use-foreign-library libharfbuzz)
15:29:46
Inline
only changing :unix "/usr/local/lib/libharfbuzz.so" works
15:30:24
Inline
i previously used that, and discovered the other stuff is not responsible for the success
15:31:26
Inline
one last attempt by putting it before the cffi:define-foreign-library
15:31:38
Inline
maybe that changes the order again
15:33:07
Inline
now i removed all but the change in the :unix line
15:35:08
Inline
what if you don't define the library ?
15:36:42
Inline
ok i now commented all the library defining form
15:37:05
Inline
and put the cffi:*foreing-library-directories* form just after it
15:37:16
Inline
not sure which it will find now
15:38:53
Inline
so it seems cffi doesn't obey the usual unix/linux search order
15:40:02
Inline
it all works with changing :unix "/usr/local/lib/libharfbuzz.so"
15:40:35
Inline
otherwise i'm not sure why *foreing-library-directores* has no influence whatsoever
15:41:32
Inline
anyway, this way i can be sure which lib will be used
15:42:03
Inline
independent of the system provided ones
16:08:24
Inline
ok i made yours run as a separate process
16:10:52
Inline
http://dpaste.com/1Y1JG1F
16:11:38
Inline
and i don't need the clim:disown-frame fm frame form cause it's not a child sheet
16:12:26
Inline
otherwise it complains on :quit itself
16:13:40
Inline
and your initialize-runtime-globals seems to fail too somehow
16:14:50
Inline
but it maybe that's my failure, some hard-coded path in my init file maybe
16:19:34
Inline
and i have to always remind myself to change that line when i repull your stuff.....
16:20:21
Inline
or maybe i just forget todo a ldconfig -v after changing ld.so.conf
16:20:27
Inline
and that was the issue ?