Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Gnuplot builder #2339

Merged
merged 61 commits into from
Dec 12, 2022
Merged

Add Gnuplot builder #2339

merged 61 commits into from
Dec 12, 2022

Conversation

VarLad
Copy link
Contributor

@VarLad VarLad commented Jan 2, 2021

This again is incomplete!
@giordano Your kind help is yet again needed my friend!

@VarLad
Copy link
Contributor Author

VarLad commented Jan 2, 2021

There's an executable called gnuplot-qt, generated in libexec folder
Should I label it as ExecutableProduct or something like LibraryExecutableProduct? Would BinaryBuilder still recognize it?

@giordano
Copy link
Member

giordano commented Jan 2, 2021

https://juliapackaging.github.io/BinaryBuilderBase.jl/dev/#BinaryBuilderBase.ExecutableProduct

By default, the library is searched in the bindir, but you can specify a different directory within the prefix with the dir_path argument.

@VarLad
Copy link
Contributor Author

VarLad commented Jan 2, 2021

@giordano

https://juliapackaging.github.io/BinaryBuilderBase.jl/dev/#BinaryBuilderBase.ExecutableProduct

By default, the library is searched in the bindir, but you can specify a different directory within the prefix with the dir_path argument.

So... ExecutableProduct(dir_path="libexec/gnuplot_qt", :gnuplot_qt)
???

@giordano
Copy link
Member

giordano commented Jan 2, 2021

No, ExecutableProduct("gnuplot_qt", :gnuplot_qt, dir_path="libexec").

@VarLad
Copy link
Contributor Author

VarLad commented Jan 2, 2021

@giordano

ERROR: LoadError: MethodError: no method matching ExecutableProduct(::String, ::Symbol; dir_path="libexec")
Closest candidates are:
  ExecutableProduct(::AbstractString, ::Symbol, ::Any...) at /depot/packages/BinaryBuilderBase/xqk4x/src/Products.jl:331 got unsupported keyword argument "dir_path"
  ExecutableProduct(::Vector{String}, ::Symbol) at /depot/packages/BinaryBuilderBase/xqk4x/src/Products.jl:321 got unsupported keyword argument "dir_path"
  ExecutableProduct(::Vector{String}, ::Symbol, ::Union{Nothing, AbstractString}) at /depot/packages/BinaryBuilderBase/xqk4x/src/Products.jl:321 got unsupported keyword argument "dir_path"
Stacktrace:
 [1] top-level scope
   @ /agent/_work/1/s/G/Gnuplot/build_tarballs.jl:25
in expression starting at /agent/_work/1/s/G/Gnuplot/build_tarballs.jl:25
##[error]Bash exited with code '1'.

@giordano
Copy link
Member

giordano commented Jan 2, 2021

Ugh, yeah, my fault, dir_path isn't a keyword argument: ExecutableProduct("gnuplot_qt", :gnuplot_qt, "libexec")

@VarLad
Copy link
Contributor Author

VarLad commented Jan 2, 2021

@giordano
I'm mainly seeing 3 errors....
The libiconv one

/opt/x86_64-linux-gnu/bin/../lib/gcc/x86_64-linux-gnu/4.8.5/../../../../x86_64-linux-gnu/bin/ld: encoding.o: undefined reference to symbol 'libiconv'
/opt/x86_64-linux-gnu/bin/../x86_64-linux-gnu/sys-root/usr/local/lib/libiconv.so.2: error adding symbols: DSO missing from command line

The Qt one

[17:28:49] make[4]: /workspace/destdir/bin/lrelease: No such file or directory
[17:28:49] make[4]: *** [Makefile:1498: qtgnuplot_fr.qm] Error 127
[17:28:49] make[4]: *** Waiting for unfinished jobs....

and the cairo one

[17:28:49] ../term/write_png_image.c:81:10: fatal error: cairo-pdf.h: No such file or directory
[17:28:49]  #include "cairo-pdf.h"
[17:28:49]           ^~~~~~~~~~~~~
[17:28:49] compilation terminated.

@VarLad
Copy link
Contributor Author

VarLad commented Jan 2, 2021

[17:28:49] ../term/write_png_image.c:81:10: fatal error: cairo-pdf.h: No such file or directory
[17:28:49] #include "cairo-pdf.h"
[17:28:49] ^~~~~~~~~~~~~
[17:28:49] compilation terminated.

This is weird...

sandbox:${WORKSPACE}/destdir # find ${prefix} -name cairo-pdf.h
/workspace/destdir/include/cairo/cairo-pdf.h

@VarLad
Copy link
Contributor Author

VarLad commented Jan 2, 2021

@giordano

[17:28:49] ../term/write_png_image.c:81:10: fatal error: cairo-pdf.h: No such file or directory
[17:28:49] #include "cairo-pdf.h"
[17:28:49] ^~~~~~~~~~~~~
[17:28:49] compilation terminated.

I fixed it with

make CFLAGS=-I${prefix}/include/cairo

But there are more such folders within include
How to list all the folders in include?

@giordano
Copy link
Member

giordano commented Jan 2, 2021

I have the feeling gnuplot can't be easily cross-compiled

@VarLad
Copy link
Contributor Author

VarLad commented Jan 2, 2021

I have the feeling gnuplot can't be easily cross-compiled

It might serve as a reference
Screenshot from 2021-01-03 00-29-01

@VarLad
Copy link
Contributor Author

VarLad commented Jan 2, 2021

@giordano Are you talking about Windows or MacOS?

@giordano
Copy link
Member

giordano commented Jan 2, 2021

I don't see anything useful in that screenshot.

The fact that it's trying to run a command, lrelease, worries me: it's a binary program, likely built for the target platform, it isn't very useful to us (in addition to the fact it isn't even in the Qt_jll artifact).

@VarLad
Copy link
Contributor Author

VarLad commented Jan 2, 2021

JuliaGraphics/QML.jl#104

lrelease is a part of QtLinguistTools... or so I hear...

@VarLad
Copy link
Contributor Author

VarLad commented Jan 2, 2021

@giordano
I'm opening a new PR to make a binary for this https://github.com/qt/qttools
It uses qt as a dependency, which I think we already have

How does that sound?
qttools should be the final dependency for gnuplot

@VarLad
Copy link
Contributor Author

VarLad commented Jan 2, 2021

#2340

This is a dependency to build the above package!

@ViralBShah ViralBShah closed this Nov 19, 2022
@ViralBShah ViralBShah reopened this Nov 19, 2022
@ViralBShah
Copy link
Member

My update to use the latest patch from mingw and latest stable version isn't working on windows. Seems like some simple linking thing on windows.

@barche
Copy link
Contributor

barche commented Nov 20, 2022

Took it one step further by forcing the winmain to be included, but this fails with:

win/wd2d.cpp:53:12: fatal error: prntvpt.h: No such file or directory

@ViralBShah
Copy link
Member

ViralBShah commented Nov 24, 2022

Nice! Is it good to merge? I suppose someone should try the binaries out.

@barche
Copy link
Contributor

barche commented Nov 24, 2022

I don't think it's working, unfortunately. Trying to run it gives:

test-gnuplot\bin> .\gnuplot.exe
Program 'gnuplot.exe' failed to run: The specified executable is not a valid application for this OS platform.At line:1
 char:1
+ .\gnuplot.exe
+ ~~~~~~~~~~~~~.
At line:1 char:1
+ .\gnuplot.exe
+ ~~~~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (:) [], ApplicationFailedException
    + FullyQualifiedErrorId : NativeCommandFailed

This is just starting the generated executable after unpacking the tarball generated by BB, not sure if that misses any needed setup.

@giordano
Copy link
Member

@barche
Copy link
Contributor

barche commented Nov 26, 2022

Failing with:

julia> run(`$(gnuplot()) --persist test.gnuplot`)
ERROR: IOError: could not spawn setenv(`'C:\Users\bartj\.julia\artifacts\66b1adb6061c27e0a5d34c0205c66359efd41fac\bin\gnuplot.exe' --persist test.gnuplot`,["PATH=C:\\Users\\bartj\\.julia\\artifacts\\231a53dac6fa0e5293789aac33fff0f9c0cdd033\\bin;C:\\Users\\bartj\\.julia\\artifacts\\4a2cc4b6aef321d12f704be234ed46372e67d1a2\\bin;C:\\Users\\bartj\\AppData\\Local\\Programs\\Julia-1.8.3\\bin;C:\\Users\\bartj\\.julia\\artifacts\\72037f1415327f12277eed0521c861517630a0ba\\bin;C:\\Users\\bartj\\.julia\\artifacts\\2e9a29903fddf79371cd5f82327f70ada670a234\\bin;C:\\Users\\bartj\\.julia\\artifacts\\3a34dec1472dcb90db22005558267071d9a8b913\\bin;C:\\Users\\bartj\\.julia\\artifacts\\01b969d96551292e78f0acfa204f120b09f4e7b4\\bin;C:\\Users\\bartj\\.julia\\artifacts\\5cbe7d14731ff4f280e1cdaa99b8d3b804f85ac0\\bin;C:\\Users\\bartj\\.julia\\artifacts\\e79b7522cd23369ab4425a478a2066d67e0df557\\bin;C:\\Users\\bartj\\.julia\\artifacts\\320fd25151d281a979541cea41d5df48e0e119f0\\bin;C:\\Users\\bartj\\.julia\\artifacts\\4c321ea83282f557b9ca0389a21d1227f428c35c\\bin;C:\\Users\\bartj\\.julia\\artifacts\\3764237d6451c548336209f3dc7ffa814198327d\\bin;C:\\Users\\bartj\\.julia\\artifacts\\8867311b9387088945ca854fdbd5ed302ce2e0e1\\bin;C:\\Users\\bartj\\.julia\\artifacts\\41eb25ea50f277f03154d52354602687fb1abc84\\bin;C:\\Users\\bartj\\.julia\\artifacts\\be75bce183282b09d5afa393777e1c4d09e36f6c\\bin;C:\\Users\\bartj\\.julia\\artifacts\\e5872943f1078a6397a4f4d0f760db959ec50630\\bin;C:\\Users\\bartj\\.julia\\artifacts\\027f99dde7e18a8ed89e38f995de8336a7130a3c\\bin;C:\\Users\\bartj\\.julia\\artifacts\\c38e0f0854753b42d208bf7f62aafa3100ba3880\\bin;C:\\Users\\bartj\\.julia\\artifacts\\5e6cdd29fca31b08026313af46c1db0c724ebbb2\\bin;C:\\Users\\bartj\\.julia\\artifacts\\2d50da999117a9f26877c370b0c06ce7f119be67\\bin;C:\\Users\\bartj\\.julia\\artifacts\\48a7da60b90abc7b20623102f7822d036bdeea75\\bin;C:\\Users\\bartj\\.julia\\artifacts\\c34a53538bc6c87c8b376c3f6d0d3248830003bc\\bin;C:\\Users\\bartj\\.julia\\artifacts\\4c30542eefae67acb7d51b8938627d01905b98ce\\bin;C:\\Users\\bartj\\.julia\\artifacts\\6a5456c156251deff41ae40ac8dfbb3d8c808ffe\\bin;C:\\Users\\bartj\\.julia\\artifacts\\3628616b5a5a8fd8628079ae4fb0d8948fdb37bc\\bin;C:\\Users\\bartj\\.julia\\artifacts\\266782898a47bef5cd0441562f9a5e3dae9fc9a2\\bin;C:\\Users\\bartj\\AppData\\Local\\Programs\\Julia-1.8.3\\bin\\..\\lib\\julia;C:\\Users\\bartj\\AppData\\Local\\Programs\\Julia-1.8.3\\bin\\..\\lib;C:\\Users\\bartj\\AppData\\Local\\Programs\\Julia-1.8.3\\bin ..., "PROCESSOR_ARCHITECTURE=AMD64"]): unknown error (UNKNOWN)
Stacktrace:
 [1] _spawn_primitive(file::String, cmd::Cmd, stdio::Vector{Union{RawFD, Base.Libc.WindowsRawSocket, IO}})
   @ Base .\process.jl:128
 [2] #725
   @ .\process.jl:139 [inlined]
 [3] setup_stdios(f::Base.var"#725#726"{Cmd}, stdios::Vector{Union{RawFD, Base.Libc.WindowsRawSocket, IO}})
   @ Base .\process.jl:223
 [4] _spawn
   @ .\process.jl:138 [inlined]
 [5] run(::Cmd; wait::Bool)
   @ Base .\process.jl:479
 [6] run(::Cmd)
   @ Base .\process.jl:477
 [7] top-level scope
   @ REPL[5]:1

The strange thing is that when I double-click the exe, I get a popup claiming "this app can't run on your PC". When I do the same on the old v5.4.1 exe, I get the expected "lib...dll not found" errors.

@barche
Copy link
Contributor

barche commented Dec 1, 2022

p.s. If anyone wants to check the binaries, they are here: https://github.com/barche/Gnuplot_jll.jl/releases/tag/Gnuplot-v5.4.5%2B0

I'm still debugging this too.

@ViralBShah
Copy link
Member

I am no help on Windows. I was hoping if the build works, the binaries will just work!

@mkitti
Copy link
Contributor

mkitti commented Dec 4, 2022

Remind me to take a look on Windows.

@barche
Copy link
Contributor

barche commented Dec 10, 2022

So I found out that there is another simpler executable being built, which also doesn't run. And the trigger is just adding the -L flag:

Works:

cc -g -O2  -DHAVE_CONFIG_H -I.. -o bf_test_good.exe bf_test.c 

Fails:

cc -g -O2  -L/workspace/destdir/lib -DHAVE_CONFIG_H -I.. -o bf_test_bad.exe bf_test.c

The working version runs and produces no output, with the bad version I get:

Program 'bf_test_bad.exe' failed to run: The specified executable is not a valid application for this OS platform.At li
ne:1 char:1
+ .\bf_test_bad.exe
+ ~~~~~~~~~~~~~~~~~.
At line:1 char:1
+ .\bf_test_bad.exe
+ ~~~~~~~~~~~~~~~~~
    + CategoryInfo          : ResourceUnavailable: (:) [], ApplicationFailedException
    + FullyQualifiedErrorId : NativeCommandFailed

Dependency Walker shows both exes only link to KERNEL32.DLL and MSVCRT.DLL. The built files differ in size.

@barche
Copy link
Contributor

barche commented Dec 11, 2022

It seems one of the dependencies puts the following libraries in /workspace/destdir/lib:

libgcc.a  libgcc_s.a  libmsvcrt.a

Removing these builds a working executable, but I'm going to investigate which dep does this.

@barche
Copy link
Contributor

barche commented Dec 11, 2022

Binaries are working now. The above-mentioned libraries were from CompilerSupportLibraries_jll, so I think the real bug is in that package. Current workaround is to simply remove libgcc.a libgcc_s.a libmsvcrt.a. For me this is ready to merge now.

@giordano
Copy link
Member

The above-mentioned libraries were from CompilerSupportLibraries_jll, so I think the real bug is in that package. Current workaround is to simply remove libgcc.a libgcc_s.a libmsvcrt.a.

It'd be good to know what is the problem with those libraries since we're going to use them in JuliaLang/julia#47184. CC: @vchuravy

@ViralBShah
Copy link
Member

@barche If you have merge privileges, please merge. Otherwise, let me know and I can.

@barche
Copy link
Contributor

barche commented Dec 12, 2022

@barche If you have merge privileges, please merge. Otherwise, let me know and I can.

I don't, so please, go ahead!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants