Bad system call with ECL
Hi, While testing lisp libraries on OpenBSD I noticed ECL package doesn't seem to function anymore. zmyrgel:10171$ sudo pkg_add ecl ecl-13.5.1: ok zmyrgel:10172$ ecl Bad system call (core dumped) zmyrgel:10173$ gdb ecl ecl.core GNU gdb 6.3 Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "amd64-unknown-openbsd5.5"... Core was generated by `ecl'. Program terminated with signal 12, Bad system call. Reading symbols from /usr/lib/libpthread.so.17.3...done. Loaded symbols for /usr/lib/libpthread.so.17.3 Reading symbols from /usr/lib/libpthread.so.18.0...done. Loaded symbols for /usr/lib/libpthread.so.18.0 Loaded symbols for /home/zmyrgel/bin/ecl Reading symbols from /home/zmyrgel/lib/libecl.so.13.5...done. Loaded symbols for /home/zmyrgel/lib/libecl.so.13.5 Symbols already loaded for /usr/lib/libpthread.so.17.3 Reading symbols from /usr/lib/libm.so.8.0...done. Loaded symbols for /usr/lib/libm.so.8.0 Reading symbols from /usr/lib/libc.so.68.4...done. Loaded symbols for /usr/lib/libc.so.68.4 Reading symbols from /usr/local/lib/libgmp.so.9.0...done. Loaded symbols for /usr/local/lib/libgmp.so.9.0 Reading symbols from /usr/local/lib/libgc.so.4.0...done. Loaded symbols for /usr/local/lib/libgc.so.4.0 Reading symbols from /usr/local/lib/libffi.so.0.0...done. Loaded symbols for /usr/local/lib/libffi.so.0.0 Symbols already loaded for /usr/lib/libpthread.so.18.0 Reading symbols from /usr/libexec/ld.so...done. Loaded symbols for /usr/libexec/ld.so #0 0x1398a85437ca in gettimeofday () at :2 2 : No such file or directory. in (gdb) bt #0 0x1398a85437ca in gettimeofday () at :2 #1 0x1398a857e1d2 in time (t=0x0) at /usr/src/lib/libc/gen/time.c:39 #2 0x1398a580db59 in init_random_state () at num_rand.d:94 #3 0x1398a580dc8a in ecl_make_random_state (rs=0x1398a5aeebd0) at num_rand.d:224 #4 0x1398a56ffafc in cl_boot (argc=Variable "argc" is not available. ) at main.d:692 #5 0x13969c201179 in main (argc=Variable "argc" is not available. ) at eclinitLPDTiw.c:51 Current language: auto; currently asm (gdb) zmyrgel:10174$ Any idea whats going on? Timo
Re: Bad system call with ECL
On 02/20/14 10:27, Timo Myyrä wrote: > Hi, > > While testing lisp libraries on OpenBSD I noticed ECL package doesn't seem to > function anymore. > works for me with 14/02 amd64 snapshot, maybe your pkgs are not in sync with base, in -current there is libc.so.73.1, in 5.4 there is libc.so.69 and you have libc.so.68.4 (Loaded symbols for /usr/lib/libc.so.68.4). Cheers Giovanni
Re: Bad system call with ECL
Giovanni Bechis writes: > On 02/20/14 10:27, Timo Myyrä wrote: >> Hi, >> >> While testing lisp libraries on OpenBSD I noticed ECL package doesn't seem to >> function anymore. >> > works for me with 14/02 amd64 snapshot, maybe your pkgs are not in sync with > base, in -current there is libc.so.73.1, in 5.4 there is libc.so.69 and you > have libc.so.68.4 (Loaded symbols for /usr/lib/libc.so.68.4). > Cheers > Giovanni Ah, good catch. As usually I skipped the most basic issues and tried to solve wrong problem. The root cause here was old ecl version in my $HOME/bin which I haven't updated in a while. At least this made me delve a bit to ecl code base. Seems that ecl uses poor random implementation and could be patched to use arc4random. Timo
Re: question related to the samba port on OpenBSD
On 20/02/2014 9:00 PM, Sebastian Rother wrote: Dear Brad, dear Ian, Why aint the Version number of the Samba port raised after applying the security patches? >From what I see the most recent version is samba 3.6.22 but OpenBSD includes 3.6.15+&whatever&. If all security patches to 3.6.15 where applied it should be 3.6.22 or? If just the CVE-patches got applied: What's wrong about the other Bugfixes? No new functionality was added. It would be kind if you might could answer me my question about the versioning of this port. Kind regards, Sebastian Because it's not 3.6.22. It is what is says 3.6.15+ patch level. Not all bug fixes post 3.6.15 are rolled in. Only security fixes (thanx Brad). Look, the Samba folk decided from 3.6.16 to change the build environment that had been with the 3.6 branch for 15 releases to python and waf. Unfortunately that busted how we handle shared library versioning on OpenBSD. They changed the build environment for 4.x. No issue. They could have left 3.6 that way it was seeing it was to become obsolete when the 4.1 branch was released. The world is linux and linux only, no project seems to give a rats ass about much else. If it works on linux then it must work everywhere.. Our in-ports tree waf was out of date to use. Some discussion was had about updating this. Not sure what happened after that. Ian McWilliam
Re: Failed building uuid while building postgresql-server
On 2014/02/19 21:32, TimH wrote: > With -current ports tree and latest snapshot. > > ===> Building package for p5-ossp-UUID-1.6.2p3 > Create /usr/ports/packages/amd64/all/p5-ossp-UUID-1.6.2p3.tgz > Error: > /usr/ports/pobj/uuid-1.6.2/fake-amd64/usr/local/libdata/perl5/site_perl/amd64-openbsd/auto/OSSP/uuid/uuid.bs > does not exist > Fatal error: can't continue > at /usr/libdata/perl5/OpenBSD/PkgCreate.pm line 1421. > *** Error 1 in /usr/ports/devel/uuid > (/usr/ports/infrastructure/mk/bsd.port.mk:1878 > '/usr/ports/packages/amd64/all/p5-ossp-UUID-1.6.2p3.tgz') > *** Error 1 in /usr/ports/devel/uuid > (/usr/ports/infrastructure/mk/bsd.port.mk:2426 '_internal-package') > *** Error 1 in /usr/ports/devel/uuid > (/usr/ports/infrastructure/mk/bsd.port.mk:2406 'package') > *** Error 1 in /usr/ports/devel/uuid > (/usr/ports/infrastructure/mk/bsd.port.mk:1891 > '/var/db/pkg/ossp-uuid-1.6.2p2/+CONTENTS') > *** Error 1 in /usr/ports/devel/uuid > (/usr/ports/infrastructure/mk/bsd.port.mk:2406 'install') > *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2034 > '/usr/ports/pobj/postgresql-9.3.2/.dep-devel-uuid') > *** Error 1 in /usr/ports/databases/postgresql > (/usr/ports/infrastructure/mk/bsd.port.mk:2406 'all') > > --TimH > Please send a full build log for devel/uuid, ASAP.
Re: question related to the samba port on OpenBSD
On 2014/02/20 22:44, Ian McWilliam wrote: > On 20/02/2014 9:00 PM, Sebastian Rother wrote: > >Dear Brad, dear Ian, > > > >Why aint the Version number of the Samba port raised after applying the > >security patches? > > > >>From what I see the most recent version is samba 3.6.22 but OpenBSD > >includes 3.6.15+&whatever&. > > > >If all security patches to 3.6.15 where applied it should be 3.6.22 or? > > > >If just the CVE-patches got applied: What's wrong about the other > >Bugfixes? No new functionality was added. > > > >It would be kind if you might could answer me my question about the > >versioning of this port. > > > >Kind regards, > >Sebastian > > > > > > Because it's not 3.6.22. It is what is says 3.6.15+ patch level. > > Not all bug fixes post 3.6.15 are rolled in. Only security fixes (thanx > Brad). > > Look, the Samba folk decided from 3.6.16 to change the build environment > that had been with the 3.6 branch for 15 releases to python and waf. > > Unfortunately that busted how we handle shared library versioning on > OpenBSD. > > They changed the build environment for 4.x. No issue. They could have left > 3.6 that way it was seeing it was to become obsolete when the 4.1 branch was > released. The world is linux and linux only, no project seems to give a rats > ass about much else. If it works on linux then it must work > everywhere.. > > Our in-ports tree waf was out of date to use. Some discussion was had about > updating this. Not sure what happened after that. Samba wants its own "special" waf anyway... Adding patches to revert upstream's build system changes might be appropriate, don't know..
Re: question related to the samba port on OpenBSD
On Thu, Feb 20, 2014 at 10:44:01PM +1100, Ian McWilliam wrote: > On 20/02/2014 9:00 PM, Sebastian Rother wrote: > >Dear Brad, dear Ian, > > > >Why aint the Version number of the Samba port raised after applying the > >security patches? > > > >>From what I see the most recent version is samba 3.6.22 but OpenBSD > >includes 3.6.15+&whatever&. > > > >If all security patches to 3.6.15 where applied it should be 3.6.22 or? > > > >If just the CVE-patches got applied: What's wrong about the other > >Bugfixes? No new functionality was added. > > > >It would be kind if you might could answer me my question about the > >versioning of this port. > > > >Kind regards, > >Sebastian > > > > > > Because it's not 3.6.22. It is what is says 3.6.15+ patch level. > > Not all bug fixes post 3.6.15 are rolled in. Only security fixes (thanx > Brad). > > Look, the Samba folk decided from 3.6.16 to change the build environment > that had been with the 3.6 branch for 15 releases to python and waf. > > Unfortunately that busted how we handle shared library versioning on > OpenBSD. > > They changed the build environment for 4.x. No issue. They could have left > 3.6 that way it was seeing it was to become obsolete when the 4.1 branch was > released. The world is linux and linux only, no project seems to give a rats > ass about much else. If it works on linux then it must work > everywhere.. > > Our in-ports tree waf was out of date to use. Some discussion was had about > updating this. Not sure what happened after that. waf is a huge pile of crap. I've switched the two ports that were using it to use something else, so you can do whatever you want with our in-tree waf, or you can use the bundled one. If i was to decide, i'll remove it. Landry
Re: devel/readline collides with base
On Wed Feb 19, 2014 at 07:46:46PM +0100, Christian Weisgerber wrote: > The devel/readline port clashes with the old libreadline in base. > Yes, the library is named "ereadline", but the header files still > collide. > > devel/R fails with It is fixed in new R 3.0.2 port. Will commit after portslook from David Coppa. R 3.0.2 port is ready and tested from Zé Loff, David Coppa and me. Cheers, Rafael
Re: question related to the samba port on OpenBSD
hmm, on Thu, Feb 20, 2014 at 10:44:01PM +1100, Ian McWilliam said that
> Look, the Samba folk decided from 3.6.16 to change the build
> environment that had been with the 3.6 branch for 15 releases to
> python and waf.
>
> Our in-ports tree waf was out of date to use. Some discussion was
> had about updating this. Not sure what happened after that.
i know this won't make me any friends on ports@
but waf is not the root of all evil.
the "waf philosophy" is to bundle it with a given project,
to become "part of the project". that is why it does
not "need" to be "package friendly", it is not meant
to be used from a package. if it helps, think of it
as waf == configure and not cmake or such. configure
is also always bundled and nobody cares.
so the bundled version is the definite version that
should be used. (actually the problematic projects are
the ones that dont bundle it...)
it takes a bit of getting used to, but i dont see how
it's 'much worse' then megabytes of gnu style shell
code and m4.
you do a 'waf configure ${CONFIGURE_ARGS}' then
'waf build' and lastly 'waf install'. the horror.
> Unfortunately that busted how we handle shared library versioning on
> OpenBSD.
i am not good with shared library versioning so
i cannot comment on that, but the build result
should be binaries, and those can be renamed
and copied in many ways :]
is samba4 also waf? i'll try to have a look
when i get stable internet connection in 2 weeks
time.
-f
--
if you can't see black, white has no meaning
Re: question related to the samba port on OpenBSD
On Thu, Feb 20, 2014 at 04:33:39PM +0100, frantisek holop wrote: > the "waf philosophy" is to bundle it with a given project, > to become "part of the project". that is why it does > not "need" to be "package friendly", it is not meant > to be used from a package. if it helps, think of it > as waf == configure and not cmake or such. configure > is also always bundled and nobody cares. > > so the bundled version is the definite version that > should be used. (actually the problematic projects are > the ones that dont bundle it...) > > it takes a bit of getting used to, but i dont see how > it's 'much worse' then megabytes of gnu style shell > code and m4. It's not really worse, but it's as bad. Any bundled shit like that is bound to be thoroughly untested outside linux/amd64, and hence to break horribly. The only "redeeming" quality of autohell is that we're so used to all the ways it can break that we can generally fix them fairly quickly.
Re: question related to the samba port on OpenBSD
On 2014/02/20 16:33, frantisek holop wrote:
> i know this won't make me any friends on ports@
> but waf is not the root of all evil.
>
> the "waf philosophy" is to bundle it with a given project,
> to become "part of the project". that is why it does
> not "need" to be "package friendly", it is not meant
> to be used from a package. if it helps, think of it
> as waf == configure and not cmake or such. configure
> is also always bundled and nobody cares.
The thing with autoconf is, the input files are *also* bundled,
so if we need to patch them and regenerate, we can do so with ease,
and without creating the maintenance problems that often occur if
the generated files (rather than the input files) are patched.
> so the bundled version is the definite version that
> should be used. (actually the problematic projects are
> the ones that dont bundle it...)
>
> it takes a bit of getting used to, but i dont see how
> it's 'much worse' then megabytes of gnu style shell
> code and m4.
>
> you do a 'waf configure ${CONFIGURE_ARGS}' then
> 'waf build' and lastly 'waf install'. the horror.
Before doing that, you usually need to patch the wscripts so that ports
can be in control of shared library version numbers, and looking at the
wip samba4 port, also patch to fix include directory ordering,
> i am not good with shared library versioning so
> i cannot comment on that, but the build result
> should be binaries, and those can be renamed
> and copied in many ways :]
It depends how they're built, you can't always do that with shared
libraries.
> is samba4 also waf? i'll try to have a look
> when i get stable internet connection in 2 weeks
> time.
yep. Peril-sensitive glasses recommended if you look at the samba4 port.
It starts off fine, then starts to get a bit "ugh" around line 200,
then you see ".include " and think you're done and it wasn't
actually so bad.
Then the real horrors begin ;-)
Re: Failed building uuid while building postgresql-server
On Thu, 20 Feb 2014 12:37:49 + Stuart Henderson wrote: > [...] > > Please send a full build log for devel/uuid, ASAP. > Attached a text file of the make and make install. --TimH# pwd /usr/ports/devel/uuid # make ===> ossp-uuid-1.6.2p2 depends on: groff->=1.21 -> groff-1.22.2p4 ===> Verifying specs: c m stdc++ perl ossp-uuid ===> found c.73.1 m.9.0 stdc++.57.0 perl.14.0 ossp-uuid.0.0 ===> Checking files for uuid-1.6.2 >> Fetch ftp://ftp.ossp.org/pkg/lib/uuid/uuid-1.6.2.tar.gz uuid-1.6.2.tar.gz 100% |***| 387 KB00:08 >> (SHA256) uuid-1.6.2.tar.gz: OK ===> Extracting for uuid-1.6.2 ===> Patching for uuid-1.6.2 ===> Configuring for uuid-1.6.2 Using /usr/ports/pobj/uuid-1.6.2/config.site (generated) configure: WARNING: Unrecognized options: --disable-silent-rules configure: loading site script /usr/ports/pobj/uuid-1.6.2/config.site shtool:echo:Warning: unable to determine terminal sequence for bold mode Configuring OSSP uuid (Universally Unique Identifier), version 1.6.2 (04-Jul-2008) checking whether make sets $(MAKE)... (cached) yes checking for gcc... cc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... (cached) o checking whether we are using the GNU C compiler... (cached) yes checking whether cc accepts -g... (cached) yes checking for cc option to accept ISO C89... none needed checking for compilation debug mode... disabled checking how to run the C preprocessor... cc -E checking for grep that handles long lines and -e... (cached) /usr/bin/grep checking for egrep... (cached) /usr/bin/egrep checking for ANSI C header files... (cached) yes checking for sys/types.h... (cached) yes checking for sys/stat.h... (cached) yes checking for stdlib.h... (cached) yes checking for string.h... (cached) yes checking for memory.h... (cached) yes checking for strings.h... (cached) yes checking for inttypes.h... (cached) yes checking for stdint.h... (cached) yes checking for unistd.h... (cached) yes checking whether to build against external Dmalloc library... no checking build system type... x86_64-unknown-openbsd5.5 checking host system type... x86_64-unknown-openbsd5.5 checking for a sed that does not truncate output... (cached) /usr/bin/sed checking for fgrep... (cached) /usr/bin/fgrep checking for ld used by cc... /usr/bin/ld checking if the linker (/usr/bin/ld) is GNU ld... yes checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B checking the name lister (/usr/bin/nm -B) interface... BSD nm checking whether ln -s works... yes checking the maximum length of command line arguments... (cached) 131072 checking whether the shell understands some XSI constructs... yes checking whether the shell understands "+="... no checking for /usr/bin/ld option to reload object files... -r checking how to recognize dependent libraries... match_pattern /lib[^/]+(\.so\.[0-9]+\.[0-9]+|\.so|_pic\.a)$ checking for ar... (cached) ar checking for strip... (cached) strip checking for ranlib... (cached) ranlib checking command to parse /usr/bin/nm -B output from cc object... ok checking for dlfcn.h... (cached) yes checking for objdir... .libs checking if cc supports -fno-rtti -fno-exceptions... no checking for cc option to produce PIC... -fPIC -DPIC checking if cc PIC flag -fPIC -DPIC works... yes checking if cc static flag -static works... yes checking if cc supports -c -o file.o... yes checking if cc supports -c -o file.o... (cached) yes checking whether the cc linker (/usr/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... openbsd5.5 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes checking whether we are using the GNU C++ compiler... (cached) yes checking whether c++ accepts -g... (cached) yes checking how to run the C++ preprocessor... c++ -E checking for gethostname in -lnsl... no checking for gethostbyname in -lnsl... no checking for accept in -lsocket... no checking for va_copy() function... yes checking for sys/types.h... (cached) yes checking for sys/param.h... (cached) yes checking for sys/time.h... (cached) yes checking for sys/socket.h... (cached) yes checking for sys/sockio.h... (cached) yes checking for sys/ioctl.h... (cached) yes checking for sys/select.h... (cached) yes checking for netdb.h... (cached) yes checking for ifaddrs.h... yes checking for net/if.h... (cached) yes checking for net/if_dl.h... yes checking for net/if_arp.h... (cached) yes checking for netinet/in.h...
Re: question related to the samba port on OpenBSD
On 20/02/14 6:44 AM, Ian McWilliam wrote: They changed the build environment for 4.x. No issue. They could have left 3.6 that way it was seeing it was to become obsolete when the 4.1 branch was released. The world is linux and linux only, no project seems to give a rats ass about much else. If it works on linux then it must work everywhere.. With regard to the shared library handling it is not a matter of Linux versus everyone else. It is OpenBSD versus a lot of the other major OS's in use. A lot of the other major operating systems that are in use handle shared libraries in the same manner be it Linux, Solaris, FreeBSD, NetBSD, DragonFly and there are few others. If people really want things to change they have to be involved with upstream projects. Just ranting and raving about things and having little to no involvement will not change anything. -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
Re: Failed building uuid while building postgresql-server
On 2014/02/20 08:36, TimH wrote: > On Thu, 20 Feb 2014 12:37:49 + > Stuart Henderson wrote: > > [...] > > > > Please send a full build log for devel/uuid, ASAP. > > > > Attached a text file of the make and make install. Not quite sure what's going on then.. You have a "Generating a Unix-style Makefile" which I don't, and have the "Running Mkbootstrap for OSSP::uuid ()" and "chmod 644 uuid.bs" lines before ...xsubpp -typemap... whereas I have them afterwards. (I wanted to jump on this because I had seen some build errors in perl ports earlier, specifically p5-X-Osd and p5-GDBM_File, though after a fresh "make build" from the same source tree, this issue went away ... odd.) You don't have anything installed/upgraded locally via cpan do you? > # pwd > /usr/ports/devel/uuid > # make > ===> ossp-uuid-1.6.2p2 depends on: groff->=1.21 -> groff-1.22.2p4 > ===> Verifying specs: c m stdc++ perl ossp-uuid > ===> found c.73.1 m.9.0 stdc++.57.0 perl.14.0 ossp-uuid.0.0 > ===> Checking files for uuid-1.6.2 > >> Fetch ftp://ftp.ossp.org/pkg/lib/uuid/uuid-1.6.2.tar.gz > uuid-1.6.2.tar.gz 100% > |***| >387 KB00:08 > >> (SHA256) uuid-1.6.2.tar.gz: OK > ===> Extracting for uuid-1.6.2 > ===> Patching for uuid-1.6.2 > ===> Configuring for uuid-1.6.2 > Using /usr/ports/pobj/uuid-1.6.2/config.site (generated) > configure: WARNING: Unrecognized options: --disable-silent-rules > configure: loading site script /usr/ports/pobj/uuid-1.6.2/config.site > shtool:echo:Warning: unable to determine terminal sequence for bold mode > Configuring OSSP uuid (Universally Unique Identifier), version 1.6.2 > (04-Jul-2008) > checking whether make sets $(MAKE)... (cached) yes > checking for gcc... cc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... (cached) o > checking whether we are using the GNU C compiler... (cached) yes > checking whether cc accepts -g... (cached) yes > checking for cc option to accept ISO C89... none needed > checking for compilation debug mode... disabled > checking how to run the C preprocessor... cc -E > checking for grep that handles long lines and -e... (cached) /usr/bin/grep > checking for egrep... (cached) /usr/bin/egrep > checking for ANSI C header files... (cached) yes > checking for sys/types.h... (cached) yes > checking for sys/stat.h... (cached) yes > checking for stdlib.h... (cached) yes > checking for string.h... (cached) yes > checking for memory.h... (cached) yes > checking for strings.h... (cached) yes > checking for inttypes.h... (cached) yes > checking for stdint.h... (cached) yes > checking for unistd.h... (cached) yes > checking whether to build against external Dmalloc library... no > checking build system type... x86_64-unknown-openbsd5.5 > checking host system type... x86_64-unknown-openbsd5.5 > checking for a sed that does not truncate output... (cached) /usr/bin/sed > checking for fgrep... (cached) /usr/bin/fgrep > checking for ld used by cc... /usr/bin/ld > checking if the linker (/usr/bin/ld) is GNU ld... yes > checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B > checking the name lister (/usr/bin/nm -B) interface... BSD nm > checking whether ln -s works... yes > checking the maximum length of command line arguments... (cached) 131072 > checking whether the shell understands some XSI constructs... yes > checking whether the shell understands "+="... no > checking for /usr/bin/ld option to reload object files... -r > checking how to recognize dependent libraries... match_pattern > /lib[^/]+(\.so\.[0-9]+\.[0-9]+|\.so|_pic\.a)$ > checking for ar... (cached) ar > checking for strip... (cached) strip > checking for ranlib... (cached) ranlib > checking command to parse /usr/bin/nm -B output from cc object... ok > checking for dlfcn.h... (cached) yes > checking for objdir... .libs > checking if cc supports -fno-rtti -fno-exceptions... no > checking for cc option to produce PIC... -fPIC -DPIC > checking if cc PIC flag -fPIC -DPIC works... yes > checking if cc static flag -static works... yes > checking if cc supports -c -o file.o... yes > checking if cc supports -c -o file.o... (cached) yes > checking whether the cc linker (/usr/bin/ld) supports shared libraries... yes > checking whether -lc should be explicitly linked in... yes > checking dynamic linker characteristics... openbsd5.5 ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... yes > checking if libtool supports shared libraries... yes > checking whether to build shared libraries... yes > checking whether to build static libraries... yes > checking whether we are using the GNU C++ compiler... (cached) yes > checking wheth
Unbreak lang/seed7 on hppa
Brian asked me to compile and to test the last version of seed7 on hppa.
The result is a little weird, so let me know if you have a better fix or
just give me the OKs.
Apparently gmake doesn't honor ALL_TARGET on hppa. I tried also running
directly "gmake -f makefile depend s7 s7c" within WRKSRC or removing
ALL_TARGET from the port makefile and adding "all: depend s7 s7c" to
WRKSRC/makefile". Nothing worked. gmake doesn't run "depend".
Index: Makefile
===
RCS file: /cvs/ports/lang/seed7/Makefile,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile
--- Makefile19 Jan 2014 20:21:01 - 1.14
+++ Makefile20 Feb 2014 21:08:32 -
@@ -1,8 +1,7 @@
# $OpenBSD: Makefile,v 1.14 2014/01/19 20:21:01 bcallah Exp $
-BROKEN-hppa = SIGILL compiling prg/s7c
-
V =20140119
+REVISION = 0
COMMENT = high-level, extensible programming language
DISTNAME = seed7_05_${V}
PKGNAME = seed7-${V}
@@ -26,7 +25,8 @@ MAKE_FLAGS = CC="${CC}" LDFLAGS="-Wl,--g
MAKE_ENV +=S7_LIB_DIR=${TRUEPREFIX}/lib/seed7/bin \
SEED7_LIBRARY=${TRUEPREFIX}/lib/seed7/lib
MAKE_FILE =makefile
-ALL_TARGET = depend s7 s7c
+# Surprisingly, ALL_TARGET doesn't work on HPPA.
+#ALL_TARGET = depend s7 s7c
CFLAGS += -I${X11BASE}/include
@@ -36,6 +36,12 @@ WRKSRC = ${WRKDIST}/src
post-patch:
perl -pi -e "s,-O2,${CFLAGS},g" ${WRKSRC}/makefile
perl -pi -e "s,/usr,${TRUEPREFIX},g" ${WRKDIST}/doc/s7{,c}.1
+
+do-build:
+ cd ${WRKSRC} && \
+ ${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM} ${MAKE_FLAGS} -f ${MAKE_FILE}
depend && \
+ ${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM} ${MAKE_FLAGS} -f ${MAKE_FILE} s7
&& \
+ ${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM} ${MAKE_FLAGS} -f ${MAKE_FILE} s7c
do-install:
${INSTALL_PROGRAM} ${WRKDIST}/bin/s7{,c} ${PREFIX}/bin
Re: Failed building uuid while building postgresql-server
On Thu, 20 Feb 2014 21:00:09 + Stuart Henderson wrote: > On 2014/02/20 08:36, TimH wrote: > > On Thu, 20 Feb 2014 12:37:49 + > > Stuart Henderson wrote: > > > [...] > > > > > > Please send a full build log for devel/uuid, ASAP. > > > > > > > Attached a text file of the make and make install. > > Not quite sure what's going on then.. You have a "Generating a > Unix-style Makefile" which I don't, and have the "Running Mkbootstrap > for OSSP::uuid ()" and "chmod 644 uuid.bs" lines before ...xsubpp > -typemap... whereas I have them afterwards. > > (I wanted to jump on this because I had seen some build errors in > perl ports earlier, specifically p5-X-Osd and p5-GDBM_File, > though after a fresh "make build" from the same source tree, this > issue went away ... odd.) > > You don't have anything installed/upgraded locally via cpan do you? I installed local::lib via cpan before this. I always do as there is no port. --TimH
Re: Unbreak lang/seed7 on hppa
On 2/20/2014 4:29 PM, Juan Francisco Cantero Hurtado wrote:
Brian asked me to compile and to test the last version of seed7 on hppa.
The result is a little weird, so let me know if you have a better fix or
just give me the OKs.
So I'm assuming it builds correctly with this fix? But does it work?
Apparently gmake doesn't honor ALL_TARGET on hppa. I tried also running
directly "gmake -f makefile depend s7 s7c" within WRKSRC or removing
ALL_TARGET from the port makefile and adding "all: depend s7 s7c" to
WRKSRC/makefile". Nothing worked. gmake doesn't run "depend".
Blah. That is pretty crappy. I really hope there's a better fix.
~Brian
Index: Makefile
===
RCS file: /cvs/ports/lang/seed7/Makefile,v
retrieving revision 1.14
diff -u -p -r1.14 Makefile
--- Makefile19 Jan 2014 20:21:01 - 1.14
+++ Makefile20 Feb 2014 21:08:32 -
@@ -1,8 +1,7 @@
# $OpenBSD: Makefile,v 1.14 2014/01/19 20:21:01 bcallah Exp $
-BROKEN-hppa = SIGILL compiling prg/s7c
-
V = 20140119
+REVISION = 0
COMMENT = high-level, extensible programming language
DISTNAME =seed7_05_${V}
PKGNAME = seed7-${V}
@@ -26,7 +25,8 @@ MAKE_FLAGS = CC="${CC}" LDFLAGS="-Wl,--g
MAKE_ENV += S7_LIB_DIR=${TRUEPREFIX}/lib/seed7/bin \
SEED7_LIBRARY=${TRUEPREFIX}/lib/seed7/lib
MAKE_FILE = makefile
-ALL_TARGET = depend s7 s7c
+# Surprisingly, ALL_TARGET doesn't work on HPPA.
+#ALL_TARGET = depend s7 s7c
CFLAGS += -I${X11BASE}/include
@@ -36,6 +36,12 @@ WRKSRC = ${WRKDIST}/src
post-patch:
perl -pi -e "s,-O2,${CFLAGS},g" ${WRKSRC}/makefile
perl -pi -e "s,/usr,${TRUEPREFIX},g" ${WRKDIST}/doc/s7{,c}.1
+
+do-build:
+ cd ${WRKSRC} && \
+ ${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM} ${MAKE_FLAGS} -f ${MAKE_FILE} depend
&& \
+ ${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM} ${MAKE_FLAGS} -f ${MAKE_FILE} s7
&& \
+ ${SETENV} ${MAKE_ENV} ${MAKE_PROGRAM} ${MAKE_FLAGS} -f ${MAKE_FILE} s7c
do-install:
${INSTALL_PROGRAM} ${WRKDIST}/bin/s7{,c} ${PREFIX}/bin
