freenode/#ecl - IRC Chatlog
Search
17:23:16
jmercouris
hi everyone, I'm trying to compile ecl and getting the following error on OSX: https://pastebin.com/RfhUeByx
18:04:50
pjb
jmercouris: the usual way to compile free software is: ./configure --prefix=/usr/local && make && sudo make install
18:09:52
jmercouris
sorry I didn't catch it, I understand this is a case of rtfm, but I don't the fm is very good here :P
18:10:39
jmercouris
it doesn't mention anything about that in "INSTALL", only for cross platform compilation
18:14:36
jackdaniel
pjb: please refrain for throwing "fucks", you may put #!$!@ instead if you feel you need these
18:14:36
pjb
In the old times, we didn't have Internet. We didn't even have phone lines, let alone modems!
18:15:55
pjb
jmercouris: you can know the flag by executing the first fucking command: ./configure --help
18:15:56
jackdaniel
so you can't simply "copy" libecl.dylib into your bundle unless you modify configure scripts
18:17:00
jackdaniel
the reason is that ECL needs to know libecl.so and ECL includes path is because they are used in ECL compiler
18:18:06
jackdaniel
therefore, "fixing" this issue isn't trivial at all (it's not something we couldn't solve given enough time and motivation)
18:18:48
jackdaniel
for instance that's one of the reasons why make check needs to be run *after* make install
18:21:45
pjb
I mean, to produce 'fasl', ie. .o it shouldn't be needed. Only to produce linked binaries.
18:21:52
jackdaniel
fwiw if you build without so support, you may compile with libecl.a (so ecl binary doesn't depend on anything), but you still need it
18:23:12
pjb
I can imagine a lot of situations where it would be good to be able to use libecl.so et al. from any place, so it would be nice if it was a parameter to the cl_boot() function, either as environment variable or explicit option…
18:23:37
jackdaniel
pjb: ah, that's what you mean - for specific target flags you may look at src/cmp/cmpdefs.lsp
18:24:05
jackdaniel
pjb: I can see some positive scenarios too, but I don't have time nor energy to change that
18:25:51
jackdaniel
yes, but this solution is not tested nor documented, it won't gain any support from me too probably
18:27:05
jackdaniel
what's more, I've seen cross-compilation extension (which is broken now) which enabled to compile against libecl from different architecture
18:28:12
pjb
There are at least 2 situations where it would be useful: Android apps, and MacOSX apps. (Of course, iOS apps too, eventually, but it will be very close to MacOSX).
18:29:31
pjb
In both cases, the system actually provide the path of the available libraries (or rather, it's possible for the application to discover them), so something automatic could be implemented. This would probably be the right thing to do, once we post a feature request ;-)
18:31:05
jackdaniel
in case of Android/iOS it doesn't make much sense unless you have gcc on these systems
18:31:20
jackdaniel
if you are not after native compilation with gcc, bytecodes compiler doesn't requiere libecl
18:32:00
jackdaniel
I believe you, but that would require also redesigning ECL compiler which relies on command line and files
18:32:33
pjb
But you're right, the bytecode compiler would be sufficient on Android and iOS. On MacOSX, gcc (ie. clang) can be used.