I am trying to build GridDB from source code on MacOS as recommended How to setup GridDB on macOS with instructions https://docs.griddb.net/gettingstarted/using-source-code/#build-a-server-and-client-java.
During the automake step, I get the following warning(s) for many source files:
3rd_party/MessagePack/Makefile.am:8: warning: source file '$(srcdir)/src/objectc.c' is in a subdirectory,
3rd_party/MessagePack/Makefile.am:8: but option 'subdir-objects' is disabled
Has anyone else had this? Any advice of how to make solve this warning? Is it critical in the make process?
There is a subtle difference between a warning and an error.
Both indicate problems, but while an error indicates a fatal problem that requires a solution right now, a warning is just that: a hint that there's a potential problem.
So: there's no need to solve anything right now.
As a user (of GridDB), you (normally) can ignore any such warning.
However, the maintainers (of GridDB) should look into that, as the warning might turn into an error as the world outside evolves.
Having said that, afaict not using subdir-objects with sources in subdirectories is not a problem per se, and some might prefer it that way. automake tries to push towards subdir-objects, as it fixes problems if you have multiple files with the same name in different directories. However, this (multiple same-named files in different directories) is not the case here.
Related
I first attempted this by getting the stock source from OpenSSL's website. That wasn't fun.
Then I clued in, and I got the source from here.
When I try to build from Xcode, it fails with several warnings and 1 error.
/Users/x/OpenSSL098-OpenSSL098-76.200.2/src/crypto/x509/x509_vfy_apple.c:29:10: Did not find header 'TrustEvaluationAgent.h' in framework 'TrustEvaluationAgent' (loaded from '/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.15.sdk/System/Library/PrivateFrameworks')
I had assumed that the patches included in this tarball were already applied, and when I attempt to run the bash script to do that, it complains that there is no (openssl) source tarball... that's ok (I think), there is already a populated src/ directory. I modified the bash script enough that it would ignore that, and indeed, when it goes to patch it gripes the patches are already applied. The README.rtf file (Apple's) is suggestive that this is only if I wish to use the patches against a later version of the source, which I'm not much interested in.
It's not clear to me if my Xcode is just mangled beyond recognition, if I'm missing some dependency, or if I don't know what I'm doing within the Xcode interface (much more comfortable on the command line).
I did find this, which seems like a related issue... but I cannot find the source code he suggests needs to be uncommented (nor how to remove the references from the project file).
Can anyone point me in the right direction?
But for the unclear English, the instructions in the second link are correct.
Delete the x509_vfy_apple.c file from the treeview on the left, it will be in the Source/crypto/x509 folder. Then in x509_vfy.c (same folder), there will be an #if directive near line 76. It's defined as...
#if __APPLE__
Make that...
#if 0
Somehow I brainfarted on this and made it #if 1 on the first try, and then dismissed the instructions as not working. Commenting this out would also work, or just nuking the entire directive for that matter.
Still seems to compile with a zillion warnings, but I'm not even sure that just isn't what you get with a 7 year old version of openssl.
My knowledge on Linux is very poor, so don't go too hard on me, please.
I tried to create a bootable CD-ROM(ISO image) from memtest86's source code.
I followed the instruction in user manual, type "make iso", but I got the error message below:
=====================================
make[1]: Leaving directory `/home/chris/src'
./makeiso.sh
make: ./makeiso.sh: Command not found
make: *** [iso] Error 127
=====================================
I have searched error 127, and I found this Make, error 127
I think my path is correct, so is binary a problem?
My system is 64 bits.
The source code can be downloaded here link
Is there a particular reason you want to compile it yourself? You may save some hassle by downloading the prebuilt .iso files. Aside from that, there's a lot of confusion going on here to the point that I'm not sure what's going on. There's memtest86 and memtest86+, which are two different products with a common origin. Some of the references I found to memtest86 are actually for memtest86+, which makes this all the more murky. There's also a memtest86++, which doesn't do much to make my head stop spinning.
Memtest86 has a downloadable .iso image available which includes the source code, and at a quick glance it appears to be the source code you also have so I think this is the one you've got. The Makefile references makeiso.sh, but it isn't included in the source at all. I have no explanation for why this would be or how to resolve it. You might try copying the file from one of the other forked projects, but I couldn't guess whether that will actually work or if there are other files that might be missing as well. I'd suggest you contact their support for help.
Memtest86+ appears to have a much more complete source code repository; for example the makeiso.sh file is included here. If memtest86 isn't working for you, you may wish to consider memtest86+ (I have no idea of the differences between the two or merits of each; I'm just proposing an alternative since the first isn't compiling for you).
In summary, I think your best options are (1) contact support for help, (2) use the prebuilt .iso file instead of compiling yourself, or (3) try an alternative program.
In my attempt to compile GCC I noticed that while ./configure doesn't yield error messages and returns an error code of 0, there are still errors logged in config.log, which do later on cause make to fail. So, why doesn't configure fail already? Or does make modify config.log later on?
config.log contains the output of all configure probes. Some of them are expected to fail. For example, frequently Autoconf probes for several different possible alternative implementations of particular functionality, and some of them are expected to fail depending on the characteristics of your system.
It's therefore up to the author of the Autoconf configure.ac script to explicitly fail the configure step if the results are not viable. Some people do this when writing their configure.ac and some don't. Sometimes it can be quite hard to know at configure time whether a particular set of findings are viable. There's also a reasonable argument that it's easier to diagnose problems during the build, later on, than to issue an error message from configure and make people search through config.log for the details. That's particularly the case if the problems are relatively obscure.
The short answer is that configure didn't fail because the people who wrote the configure script you're running didn't program it to fail for the specific errors that you're seeing, for one reason or another.
I'm trying to build apple's opensource libc (from http://www.opensource.apple.com/source/Libc/Libc-763.11/) on my OS X 10.6.8 laptop. This is in an attempt to essentially get a locally generated replica of /usr/lib/libSystem.B.dylib, which I intend to experiment on further.
I see a couple basic roadblocks though (unless, obviously, I'm missing something basic):
No instructions on how to do the build. There are a couple of Makefiles in the URL I reference above, but they fail to build when I try to do straightforward makes:
$make -f Makefile
Makefile:14: *** missing separator. Stop.
I suspect the source available for download is incomplete. Not incomplete in the sense that Apple isn't revealing all of the changes, but incomplete in the sense that there are source files that were (presumably) not modified by Apple, so isn't included in the collection. For example, I don't see the implementation of the "open" call (which, in the gnu libc hierarchy, is available at io/open.c)
The closest reference I could find after some googling was this: http://www.projectosx.com/forum/index.php?showtopic=1922&st=0&p=12457&#entry12457 but it still isn't close enough for my taste!
Any pointers?
Thanks!
Only some general pointers (although some links are discussing older OSX versions):
http://darwinbuild.macosforge.org/trac/ticket/6
http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-projects/darwin/overlay/sys-libs/libc-darwin/libc-darwin-391.ebuild?view=markup&sortby=log
http://althenia.net/wiki/darwin#standard_library_libc
http://dev.gentoo.org/~vapier/CROSS-COMPILE-GUTS
http://www.raccoonfink.com/fink/darwin-cross/
There is a bug in RHEL5's gcc-4.3.2 with which we are stuck. As a work-around we have extracted the missing object and put it in an object file. Adding this object file to every link makes the problem go away.
While adding it directly to LDFLAGS seems like a good solution, this doesn't work since e.g. libtool cannot cope with non-la files in there.
A slightly more portable solution seems to be to directly patch the gcc spec to add this to every link. I came up with
*startfile:
+ %{shared-libgcc:%{O*:%{!O0:/PATH/TO/ostream-inst.o}}}
where ostream-inst.o is added to the list of startfiles used in the link when compiling a shared library with optimizations.
Trying to compile boost with this spec gives some errors though since its build directly sets some objects with ld's --startgroup/--endgroup.
How should I update that spec to cover that case as well, or even better, all cases?
Go through this URL Specifying subprocesses and the switches to pass to them and GCC Command Options
If this help you, thats great.
I know this is not the answer you want to hear (since you specified otherwise in your question), but you are running into trouble here and are likely to run into more since your compiler is buggy. You should find a way of replacing it, since you'll find yourself writing even more work-around code the next time some obscure build system comes along. There's not only bjam out there.
Sorry I can't help you more. You might try simply writing a .lo file by hand (it's a two-liner, after all) and insert it into your LDFLAGS.
If it is a bug of GCC 4.3, did you try to build (by compiling from sources) and use a newer GCC. GCC 4.6.2 is coming right now. Did you consider using it?