Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.forth > #54617 > unrolled thread

libpng12 makes it impossible to compile gforth with C bindings

Back to article view | Back to comp.lang.forth

Contents

  libpng12 makes it impossible to compile gforth with C bindings anotherreepca@gmail.com - 2017-02-03 18:46 -0800
    Re: libpng12 makes it impossible to compile gforth with C bindings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-06 08:53 +0000
    Re: libpng12 makes it impossible to compile gforth with C bindings caleb.ristvedt@cune.org - 2017-02-08 14:59 -0800
      Re: libpng12 makes it impossible to compile gforth with C bindings anotherreepca@gmail.com - 2017-02-08 19:53 -0800
      Re: libpng12 makes it impossible to compile gforth with C bindings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-09 10:37 +0000
        Re: libpng12 makes it impossible to compile gforth with C bindings anotherreepca@gmail.com - 2017-02-12 02:59 -0800
          Re: libpng12 makes it impossible to compile gforth with C bindings anotherreepca@gmail.com - 2017-02-12 13:04 -0800
            Re: libpng12 makes it impossible to compile gforth with C bindings anotherreepca@gmail.com - 2017-02-12 15:24 -0800
          Re: libpng12 makes it impossible to compile gforth with C bindings anton@mips.complang.tuwien.ac.at (Anton Ertl) - 2017-02-13 14:18 +0000
            Compilation errors anotherreepca@gmail.com - 2017-02-14 17:10 -0800

#54617 — libpng12 makes it impossible to compile gforth with C bindings

Attempted to compile gforth as per instructions in INSTALL.md, got some errors
in the "make more" stage complaining about libpng12 having a messed up header -
apparently something about not wanting to include setjmp.h again? Not sure how
to resolve that without a headache caused by manual package
management... anyway, the important part is that (perhaps because of that,
perhaps because of some other reason I didn't see in the build log) the c
interface isn't defined at all - "c-interface" gives an "undefined word"
error. Frustrating, I was hoping to use the C interface to get poll.h so I could
plop a REPL in a loop without blocking.

Any idea how to resolve this or if that's what's causing my problems with the C
interface? 

http://pastebin.com/KrUf9Vp6

[toc] | [next] | [standalone]

#54670

anotherreepca@gmail.com writes:
>Attempted to compile gforth as per instructions in INSTALL.md, got some errors
>in the "make more" stage complaining about libpng12 having a messed up header -
>apparently something about not wanting to include setjmp.h again? Not sure how
>to resolve that without a headache caused by manual package
>management... anyway, the important part is that (perhaps because of that,
>perhaps because of some other reason I didn't see in the build log) the c
>interface isn't defined at all - "c-interface" gives an "undefined word"
>error. Frustrating, I was hoping to use the C interface to get poll.h so I could
>plop a REPL in a loop without blocking.
>
>Any idea how to resolve this or if that's what's causing my problems with the C
>interface? 
>
>http://pastebin.com/KrUf9Vp6

It was not obvious how to make sense of the above, but I think I get
the gist of it now.  The link at the end is the build log, and it
shows that, while pre-building the C library wrappers, there is a
problem, apparently with unix/png.fs.

This means that unix/png.fs and unix/soillib.fs don't get their C
wrappers pre-built; if you use these, the system will try to build
them at run-time; if you don't, you will miss nothing.

Concerning C-INTERFACE, no such word is documented in the Gforth
documentation.  Maybe you are thinking of C-LIBRARY?  This exists and
works on your system, otherwise you would not see the error messages
you see.

Concerning poll(), this is already covered in unix/libc.fs, so you
don't have to deal with the definition part of the C interface to use
poll().  Just require unix/libc.fs and then call

poll ( fds nfds timeout -- r )

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#54727

Sorry, I was actually thinking of C-FUNCTION, but failed to catch that mistake in typing - that's the problem with interacting with others as a last resort, you're always tired and frustrated when you do so. \c isn't defined either, but C-LIBRARY is. Actually, after using C-LIBRARY, then \c and stuff seems to work... the manual (at least, as far as I've read) didn't seem to indicate that C-LIBRARY had to be used before C-FUNCTION could be used. It doesn't have to be used on my laptop's installation (from the Ubuntu 16.04 repositories, 0.7.2) in order to use C-FUNCTION, but does have to be used on my desktop which is using the built-from-scratch 0.7.9_20170112. I assumed that some issue in compilation was causing this difference, but it seems that was a faulty assumption. Did the usage of C-FUNCTION change from 0.7.2 and now?

Thanks.

[toc] | [prev] | [next] | [standalone]

#54733

On Wednesday, February 8, 2017 at 4:59:19 PM UTC-6, caleb.r...@cune.org wrote:
> Sorry, I was actually thinking of C-FUNCTION, but failed to catch that mistake in typing - that's the problem with interacting with others as a last resort, you're always tired and frustrated when you do so. \c isn't defined either, but C-LIBRARY is. Actually, after using C-LIBRARY, then \c and stuff seems to work... the manual (at least, as far as I've read) didn't seem to indicate that C-LIBRARY had to be used before C-FUNCTION could be used. It doesn't have to be used on my laptop's installation (from the Ubuntu 16.04 repositories, 0.7.2) in order to use C-FUNCTION, but does have to be used on my desktop which is using the built-from-scratch 0.7.9_20170112. I assumed that some issue in compilation was causing this difference, but it seems that was a faulty assumption. Did the usage of C-FUNCTION change from 0.7.2 and now?
> 
> Thanks.

... whoops, wrong user. Arg.

[toc] | [prev] | [next] | [standalone]

#54746

caleb.ristvedt@cune.org writes:
>Sorry, I was actually thinking of C-FUNCTION, but failed to catch that mist=
>ake in typing - that's the problem with interacting with others as a last r=
>esort, you're always tired and frustrated when you do so. \c isn't defined =
>either, but C-LIBRARY is. Actually, after using C-LIBRARY, then \c and stuf=
>f seems to work... the manual (at least, as far as I've read) didn't seem t=
>o indicate that C-LIBRARY had to be used before C-FUNCTION could be used. I=
>t doesn't have to be used on my laptop's installation (from the Ubuntu 16.0=
>4 repositories, 0.7.2) in order to use C-FUNCTION, but does have to be used=
> on my desktop which is using the built-from-scratch 0.7.9_20170112. I assu=
>med that some issue in compilation was causing this difference, but it seem=
>s that was a faulty assumption. Did the usage of C-FUNCTION change from 0.7=
>.2 and now?

Yes.  Apparently the idea now is to use it between C-LIBRARY and
END-C-LIBRARY.

The question is: Should we fix the documentation or the code?  Does
anybody have code that they care about and that uses C-FUNCTION
etc. outside C-LIBRARY ... END-C-LIBRARY?

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#54806

On Thursday, February 9, 2017 at 5:04:04 AM UTC-6, Anton Ertl wrote:
> caleb.ristvedt@cune.org writes:
> >Sorry, I was actually thinking of C-FUNCTION, but failed to catch that mist=
> >ake in typing - that's the problem with interacting with others as a last r=
> >esort, you're always tired and frustrated when you do so. \c isn't defined =
> >either, but C-LIBRARY is. Actually, after using C-LIBRARY, then \c and stuf=
> >f seems to work... the manual (at least, as far as I've read) didn't seem t=
> >o indicate that C-LIBRARY had to be used before C-FUNCTION could be used. I=
> >t doesn't have to be used on my laptop's installation (from the Ubuntu 16.0=
> >4 repositories, 0.7.2) in order to use C-FUNCTION, but does have to be used=
> > on my desktop which is using the built-from-scratch 0.7.9_20170112. I assu=
> >med that some issue in compilation was causing this difference, but it seem=
> >s that was a faulty assumption. Did the usage of C-FUNCTION change from 0.7=
> >.2 and now?
> 
> Yes.  Apparently the idea now is to use it between C-LIBRARY and
> END-C-LIBRARY.
> 
> The question is: Should we fix the documentation or the code?  Does
> anybody have code that they care about and that uses C-FUNCTION
> etc. outside C-LIBRARY ... END-C-LIBRARY?
> 
> - anton
> -- 
> M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
> comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
>      New standard: http://www.forth200x.org/forth200x.html
>    EuroForth 2016: http://www.euroforth.org/ef16/

I don't really have an opinion either way, but I just noticed something rather strange - using c-library like so fails (copied the example from https://github.com/shepheb/forthboy/blob/master/sdl.fs so it could very well be out of date with how it's supposed to be used now, but from what I've read of the manual it seems consistent):

Gforth 0.7.9_20170112, Copyright (C) 1995-2016 Free Software Foundation, Inc.
Gforth comes with ABSOLUTELY NO WARRANTY; for details type `license'
Type `help' for basic help
c-library sdl  ok
\c #include <SDL2/SDL.h>  ok
s" SDL2" add-lib  ok
c-function sdl-init SDL_Init n -- n  ok
end-c-library  In file included from /home/reepca/.gforth/amd64/libcc-named/sdl.c:1:0:
/usr/local/include/gforth/0.7.9_20170112/amd64/libcc.h:60:13: error: expected ‘:’, ‘,’, ‘;’, ‘}’ or ‘__attribute__’ before ‘.’ token
 #define fp x.fpx
             ^
/usr/local/include/gforth/0.7.9_20170112/amd64/libcc.h:60:13: error: expected ‘;’, ‘,’ or ‘)’ before ‘.’ token
 #define fp x.fpx
             ^

*the terminal*:5: error: libtool compile failed
end-c-library 
Backtrace:
                                         0 $7FEC3901B318 throw 
                                         1 $7FEC3901D268 compile-wrapper-function1 


But then I tried the same thing with both the lseek and libm examples in the manual and it worked fine there... I thought perhaps SDL.h was doing some weird preprocessor magic also, but it seems that include comes after the file that the errors are appearing in? I don't think there's already any SDL bindings in place to cause issues... what could be going wrong?

[toc] | [prev] | [next] | [standalone]

#54813

I've fiddled with the problem a bit manually, and it appears that it compiles fine if #include <SDL.h> comes before #include <libcc.h>, but libcc.h always comes first in the generated C wrappers. I'm not sure how to work around that other than by manually editing the generated file. Does #include <libcc.h> need to come before the other includes? 

The C preprocessor is *weird*.

[toc] | [prev] | [next] | [standalone]

#54816

Update: works on my laptop with gforth 0.7.2 also using SDL2. 

[toc] | [prev] | [next] | [standalone]

#54837

anotherreepca@gmail.com writes:
>c-library sdl  ok
>\c #include <SDL2/SDL.h>  ok
>s" SDL2" add-lib  ok
>c-function sdl-init SDL_Init n -- n  ok
>end-c-library  In file included from /home/reepca/.gforth/amd64/libcc-named=
>/sdl.c:1:0:
>/usr/local/include/gforth/0.7.9_20170112/amd64/libcc.h:60:13: error: expect=
>ed =E2=80=98:=E2=80=99, =E2=80=98,=E2=80=99, =E2=80=98;=E2=80=99, =E2=80=98=
>}=E2=80=99 or =E2=80=98__attribute__=E2=80=99 before =E2=80=98.=E2=80=99 to=
>ken
> #define fp x.fpx

The problem here is that SDL.h defines a struct containing a field
"fp", and that does not work with this macro in place.  GCC now these
days points to the definition of the macro rather than its use, which
is not quite as confusing as pointing to the use (which looks
inconspicuous).

This problem does not show up in Gforth 0.7, because in Gforth 0.7 we
were smart enough to call the corresponding macro gforth_FP.  Thank
you for reporting this bug.

In the case of your SDL library, there is no reason not to include
<SDL2/SDL.h> first, but in general the \c lines may include code that
uses stuff from libcc.h, so in general libcc.h needs to come first.
Therefore the better approach is to use names that are unlikely to
collide with other stuff (like "gforth_FP").

- anton
-- 
M. Anton Ertl  http://www.complang.tuwien.ac.at/anton/home.html
comp.lang.forth FAQs: http://www.complang.tuwien.ac.at/forth/faq/toc.html
     New standard: http://www.forth200x.org/forth200x.html
   EuroForth 2016: http://www.euroforth.org/ef16/

[toc] | [prev] | [next] | [standalone]

#54857 — Compilation errors

After the latest commit, I get a bunch of errors complaining about fp and sp in all phases of compilation (by which I mean in make, make doc, and make more), yet installation succeeds and c-library appears to work with SDL2. Not sure how that's all working, but it appears to be working somehow.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.forth

csiph-web