The Source0 field of rubygem-rdiscount.spec[1] points to http://rubygems.org/gems/rdiscount-2.0.7.gem. The gem at that location has the Discount libmarkdown library bundled in the "ext" directory and it appears that the package compiles/links/installs it. Unless I'm mistaken, that's breaking the "no bundled libraries"[2] rule. I've submitted a packaging request for Discount and hopefully it will be in Fedora soon. Perhaps the rubygem-rdiscount package should be patched to link against that, when it becomes available? [1]: http://pkgs.fedoraproject.org/cgit/rubygem-rdiscount.git/tree/rubygem-rdiscount.spec#n10 [2]: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
I've just noticed that rdiscount also bundles the markdown.7 man page from Discount too, so when trying to install both the rubygem-rdiscount package and the (now accepted and pending update) discount package, I get the following error: Transaction Check Error: file /usr/share/man/man7/markdown.7.gz from install of rubygem-rdiscount-2.0.7-2.fc18.i686 conflicts with file from package discount-2.1.6-1.fc18.i686
Sorry! I have had only limited access to the internet the last two days. So I will look for this problem today.
I just builded rubygem-rdiscount with the new source 2.0.7.3 for rawhide and excluding the man-page /usr/share/man/man7/markdown.7.gz. http://koji.fedoraproject.org/koji/taskinfo?taskID=5408354 Did it help or are they any other conflicts?
Build of rubygem-rdiscount-2.0.7.3-1 are also down for F18 and F19 und in the update stream.
That fixes the immediate problem of clashing files, yes. Thanks for that. The problem of the bundled library still remains though. From what I can tell, /usr/lib/gems/ruby/rdiscount-2.0.7.3/lib/rdiscount.so contains an internal copy of the Discount library code (libmarkdown), instead of being dynamically linked against it. I think the normal thing to do is either to patch the build system to link against the packaged libmarkdown or try to get an bundling exception.[1] I would volunteer to do the patching, but the rdiscount developer seems to have thrown away Discount's configure script and Makefile, in favor of a Rakefile, which I can't read. [1]: https://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries#Exceptions
I would like to try if I could build/link rubygem-rdiscount with/again discount and libmarkdown but I did not find a package in Fedora 18. I found the review request of discount: https://bugzilla.redhat.com/show_bug.cgi?id=740160 and a build of it for Fedora 18: https://admin.fedoraproject.org/updates/discount-2.1.6-1.fc18 but nothing seems to be pushed into Fedora 18: > yum search discount libmarkdown Loaded plugins: langpacks, presto, refresh-packagekit ============================ N/S Matched: discount ============================ rubygem-rdiscount-doc.noarch : Documentation for rubygem-rdiscount rubygem-rdiscount.x86_64 : Fast Implementation of Gruber's Markdown in C Name and summary matches mostly, use "search all" for everything. Warning: No matches found for: libmarkdown
I build your package discount and my package rubygem-rdiscount on a Fedora 17 system. Simple linking rdiscount.so to /usr/lib64/libmarkdown.so.2.1.6 did not work. ./ruby.prog /usr/share/rubygems/rubygems/custom_require.rb:60:in `require': /usr/lib64/gems/exts/rdiscount-2.0.7.3/lib/rdiscount.so: undefined symbol: Init_rdiscount - /usr/lib64/gems/exts/rdiscount-2.0.7.3/lib/rdiscount.so (LoadError) from /usr/share/rubygems/rubygems/custom_require.rb:60:in `rescue in require' from /usr/share/rubygems/rubygems/custom_require.rb:35:in `require' from /usr/share/gems/gems/rdiscount-2.0.7.3/lib/rdiscount.rb:100:in `<top (required)>' from /usr/share/rubygems/rubygems/custom_require.rb:60:in `require' from /usr/share/rubygems/rubygems/custom_require.rb:60:in `rescue in require' from /usr/share/rubygems/rubygems/custom_require.rb:35:in `require' from ./ruby.prog:3:in `<main>'
Output: [gz016@vdesk1 ruby]$ nm -D /usr/lib64/gems/exts/rdiscount-2.0.7.3/lib/rdiscount.so.orig | grep -i init 00000000000065b0 T Init_rdiscount 000000000000b240 T ___mkd_initmmiot 0000000000002a58 T _init 0000000000005ee0 T mkd_initialize [gz016@vdesk1 ruby]$ nm -D /usr/lib64/libmarkdown.so.2.1.6 | grep -i init 000000000000a660 T ___mkd_initmmiot 0000000000002b10 T _init 000000000000bfa0 T mkd_initialize [gz016@vdesk1 ruby]$
I do not think the gem really bundle the Discount libmarkdown library. It only use some of the same source files. But I think it will not be easy to change the ruby build process (gem install ...). You can go in the ext directory and enter: ruby extconf.rb This will generate a Makefile to generate rdiscount.so. I think it will not be easy to patch this Makefile to not use some C-source files and rather to link against libmarkdown. How would this Makefile look like? Indeed a better extconf.rb would needed to be written.
I made a deeper look in the sources. rubygem-rdiscount take some C files from discount that have exactly the same data content. Other C files differ a like bit. So I added this line in Rakefile that delete the files with the same content. rm_f FileList['ext/amalloc.c', 'ext/amalloc.h', 'ext/basename.c', 'ext/css.c', 'ext/docheader.c', 'ext/dumptree.c', 'ext/emmatch.c', 'ext/resource.c', 'ext/xml.c', 'ext/xmlpage.c'] So this objects form this files will not be add to rdiscount.so. I changed the Makefile to add the option: -lmarkdown Line in Makefile LOCAL_LIBS = -lmarkdown build: rm -f rdiscount.so gcc -shared -o rdiscount.so Csio.o version.o markdown.o tags.o setup.o rdiscount.o html5.o generate.o toc.o flags.o mkdio.o -L. -L/usr/lib64 -L. -Wl,-z,relro -rdynamic -Wl,-export-dynamic -m64 -lmarkdown -lruby -lpthread -lrt -ldl -lcrypt -lm -lc running a test program with the new /usr/lib64/gems/exts/rdiscount-2.0.7.3/lib/rdiscount.so library crashes: ./ruby.prog *** glibc detected *** /usr/bin/ruby: realloc(): invalid pointer: 0x0000000001347d48 *** ======= Backtrace: ========= /lib64/libc.so.6[0x3732c7b616] /lib64/libc.so.6(realloc+0x346)[0x3732c805b6] /usr/lib64/gems/exts/rdiscount-2.0.7.3/lib/rdiscount.so(mkd_document+0xca)[0x7f9410ecd48a] /usr/lib64/gems/exts/rdiscount-2.0.7.3/lib/rdiscount.so(+0x595d)[0x7f9410ec995d] /lib64/libruby.so.1.9[0x39aab50533] /lib64/libruby.so.1.9[0x39aab471a8] ... So I think it makes no sense to patch the rdiscount sources.
I see no way to link against the packaged libmarkdown. The rdiscount.so library is only a bytes greater with including the same code so I see no need to ask for an exception. I think this ticket can be closed.
RDiscount is (effectively) statically linked against Discount, since it bundles it as part of the build process. I do not, unfortunately. My limited knowledge around Ruby C extensions suggests that they have to (or are at least designed to be) only built from source.
reopened Please ask fesco for an exception.
Okay! I only want to understand it. Some more information: At a 64bit system with the install sub package "libmarkdown(-devel)" of discount and the installed package "rubygem-rdiscount" you have this shared object libraries installed: libmarkdown-rpm: /usr/lib64/libmarkdown.so /usr/lib64/libmarkdown.so.2.1.6 rubygem-rdiscount-rpm: /usr/lib64/gems/exts/rdiscount-2.0.7.3/lib/rdiscount.so Both libraries depend on building from some same C source files. Is this bundling libraries? What is the problem? The rdiscount library would only be loaded by a ruby program. require 'rdiscount' markdown = RDiscount.new( "Hello World!", :filter_html) ....
The Markdown parsing in rdiscount is done by libmarkdown. libmarkdown is a library. So I'm afraid that's bundling libraries, yes. The problems with bundling are well enumerated on the wiki page. I think the point of asking for an exception is to ensure that it's well justified and that there's a record of known cases. I don't think upstream pays much attention to API/ABI compatibility except with the code they've dumped in their tree, so I think you're probably right about it being troublesome to patch and maintain.
Gerd, would you mind to discuss this issue with upstream? I.e. if they could link against system libmarkdown if available? I think this is the most natural think to do.
I have already discussed this issue with one of gem owners (upstream). Comment 12 includes parts of the answer from David Forst. To find a solution I ask for an exception: https://fedorahosted.org/fpc/ticket/304
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle. Changing version to '20'. More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
Moving this bug back to Rawhide and marking as RFE to avoid auto-closing.
(In reply to Gerd Pokorra from comment #10) This segv is because ext/mkdio.h (in rubygem-rdiscount) says "typedef unsigned int mkd_flag_t;" where /usr/include/mkdio.h (included in libmarkdown-devel( says "typedef unsigned long mkd_flag_t;" and on 64bit size differs between int and long. i.e. removing ext/mkdio.h from rubygem-rdiscount will remove this segv. Note that with using system libmarkdown, two tests will fail. With make these two tests succeed, another configure option needs to be added when compiling discount (--with-dl=Both and --with-github-tags). Now rubygem-rdiscount-2.1.7.1-7.fc2{2,1} uses system libmarkdown.so.
rubygem-rdiscount-2.1.7.1-7.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/rubygem-rdiscount-2.1.7.1-7.fc21
rubygem-rdiscount-2.1.7.1-7.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.